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Welcome to Basic Concepts of Project Management 



■ Course material will be in english 

■ Local emergency exit procedures 

■ Celular phones 

■ Lotus Notes 

■ Examination last day 

a Atendance expectations (85%) 



Start on time 




Instructors 



Students 



Career Development Model 



The Career Development Model is the fundamental structure of the 
Professional Development Program. This model identifies core skills essential to 
all practitioners, profession skills unique to each profession and functional skills 
that address the specific technical requirements to deliver our solutions. 



Career Development Model 




[ Baste Concepts of Project Management 



©gqoggBM Corporation 





The IBM Project Management Community 



In support of our market-driven strategy, IBM will manage its bussiness as a 
project_based business. Projects are the means by which we will create 
solutions to satisfy specific client needs. The corporation will fully apply and 
integrate project management into all core business processes and system. 

- Accepted by IBM Corporate Executive 
Committee on November 19, 1996 

Project management is a critical professional discipline. 
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Project Management - A Core Competence in IBM 

Organizational competence means that : 

• Work is organized along project lines (that is, by product or division) 

• Projects are consistently funded, staffed, and managed in all business 
units, and project management has a consistent role in overall business 
processes 

• Individuals involved in projects understand their roles in individual and 
multiple projects in terms of : 

- Planning 

- Executing 

- Evaluating 

• Project outcomes can be predicted with high degrees of certainty; when 
predictions are incorrect, IBM has the knowledge and ability to adjust 
decisions and take proper corrective action early 
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Project Management Center of Excellence 



Via the web: http://w3.ibm.com/transform/project/index.html 

■ The PM/COE mission is to drive corporate programs to transform IBM to a 
project-based enterprise working with deployment teams in IBM Global 
Services (WWPMI) and Brands. Enterprise Project Management (EPM) - 
underlies the integration of project management into the fabric of IBM 
making project management systemic across the enterprise. 



Agenda 



As part of the course presentation the agenda will be 
distributed to the participants. 

We will see it now.... 
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Student Presentations 



■ Name 
a Location 

■ Years in current organization 

■ Discipline experience and team member experience JJ, 
In Groups 

■ Objectives/expectations for the course 
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Objectives 



At the end of this course, you should be able to: 

► Use project management skills 

► Build your project team 

► Prepare a useful team charter 

► Identify and validate your project requirements 

► Manage transformation of requirements into specifications 

► Use change management to control requirements 

► Prepare a Work Breakdown Structure (WBS) 

► Prepare a risk management plan 

► Establish a project estimate 

► Compile and manage reliable network schedules 

► Develop and manage project baselines 

► Use project management skills and processes to contol project 
execution 

► Prepare and execute a project closeout strategy 
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Objectives 



and you should be able to: 

► Apply Leadership concepts and techniques 

► Use PM oriented Metrics 

*■ Operate at a proper CMM level 

► Identify and apply all needed Business Controls 

► Use GS Method, Knowledge Management, Intelectual Capital 
Management, GS Risk, XSER, PCB, PM Office and CLAIM. 

► Understand and use the proper Procurement Administrative Circuits 
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Module I Team Exercise: 
Building a bridge 
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Module I - Team Exercise 
Building a bridge 



A Project Manager will be 
designated for the team for 
this particular exercise (PM 
role will be rotative within a 
group for different 
exercises). 
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Objectives 



At the end of this module, you should be able to: 



Identify the characteristics of a project and project management 
Describe the phases of a project 

Recognize the roles and responsibilities of a project manager 

Describe the matrix organization 

Outline the importance of a successful project team 

Review a project charter 

Prepare a team charter 

Describe the influence of project politics in the project management 
environment 
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Basic Definitions 



What is a program? 

■ A group of interrelated projects managed together 

What is a project? 

h A finite endeavor that: 

- Has a definite beginning and a definite end 

- Is unique 

- Consumes resources 

What is a subproject? 

■ Part of a project managed with a level of independence 
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Basic Definitions (continued) 



What is project management? 

■ Applying knowledge, skills, and toots to project activities, subprojects, 
and programs to meet or exceed stakeholder needs and 
expectations 

Project management involves managing: 

■ Communication 

■ Coordination 

■ Team Building 

■ Issues Resolution 

■ Integration 

■ Execution 

■ Planning 

■ Budgeting 

■ Control 

■ Customer Expectations 
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Phases of a Project 



Projects are usually divided into phases 

Collectively, the phases are called the project life cycle 

Project life cycles are similar but rarely identical 

Initial Final 
Phase Intermediate Phase Phase 



CRM 



IPD 



PMBOK 




Concept 



Concept 



Plan 



Develop 



Develop 
Qualify 



Execute 



Finish 



Start 



Finish 
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Resource Use Across Phases of a Project 

The curve represents the change in level of effort required in a typical life cycle 



Initial 



Final 



CRM 



IPD 



PMBOK 



Cost anc 

Staffing 

Level 
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Concept 


Plan j 
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Develop 
Qualify 




Concept 




Execute 


Finish 



Start 
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Projects = Small Businesses 



Both projects and small businesses: 

■ Consume resources o Have financial targets to: 

- Staff - Work within a budget 

- Equipment - Control costs 

- Facilities - Generate revenues and profit 

■ Have stakeholders who: - Ensure a positive cash flow 

- Allocate equity capital 
(assets - liabilities) 

- Define objectives 

- Demand returns on capital 

■ Have critical success factors 

- Cost 

- Schedule 

- Quality 
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The Project Manager and Project Stakeholders 

The project manager is: 

■ Accountable for the project 

■ The single point of contact for the project 

■ Responsible for identifying potential stakeholders 
Project stakeholders are: 

■ Those people who have an interest or role in the project 

Line management Product safety 




Stakeholder Analysis 



» Identify all stakeholders (any individual or entity that has something at stake 
(gain or loss) with the success of your project 

■ Determine is friend or foe 

« Utilize friends to bring foes on line 

■ Develop and implement a win/win strategy to bring foes on line 
Remember: 

- There is always something with which you can "hook" your foes into the 
success of your project 

- You don't have to "like" someone to invest them in the success of your 
project 

- Keep your own ego where it needs to be to ensure your project's success 




Roles of a Project Manager 

Plan the project's: 

■ Technical activities 

■ Project management activities 

Manage the triple constraints to client/project sponsor satisfaction: 

■ Schedule Schedule 

■ Cost 

■ Specifications 



Cost Specifications 

Organize the project, which includes: 

■ Forming the project team 

■ Setting up systems to document the project 

■ Setting up project plans and processes by which the project will be controlled 




Roles of a Project Manager (continued) 



You will manage (or direct) the project by: 



Tracking the technical performance aspects of the project schedule and cost 

Tracking the financial performance of the project 

Assessing and managing the project's risk factors 

Dealing with issues and problems that occur during the project 

Tracking suppliers' performance against their contracts 

Ensuring client/project sponsor satisfaction 

Building and maintaining the morale of the project team 

Communicating with all stakeholders 

Managing the entire team, including contractors 

Tracking team member performance 

Using a change control process to control scope 

Closing the project 



Follow defined processes that enable you to plan, organize, and manage the 
project 
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Key Competencies of a Successful Project Manager 



Long-range perspective: An individual's tendency lo consider long-term implications 
and possibilities when acting or making decisions 

Risk-taking/venturesomeness: An individual's tendency to try new ideas and take 
action in the face of potential risks 

Clarification of goals: An individual's ability to define and clarify project and individual 
goals 

Innovation/creativity: An individual's ability to apply imaginative thinking and 
generate original ideas and thoughts regarding business issues 
Participative problem solving: The extent to which an individual solicits and applies 
the ideas and knowledge of others in solving problems 

Systematic thinking and planning: An individual's ability to apply a systematic 
approach lo thinking through issues and planning team and individual activities 
Strategic inquiry: An individual's tendency to sort through and handle complex or 
conflicting information and to prioritize issues and alternatives 
Political awareness: An individual's ability to develop and maintain a sensitivity to 
personal and organizational relationships and to their ramifications for a project 
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Key Competencies of a Successful Project Manager (cont.) 



■ Team member facilitation: An individual's demonstrated ability to coach and develop 
project team members 

* Team development. An individual's ability to develop teamwork and improve the 
coordinated functioning of project team members 

■ Assertiveness: An individual's tendency to assert himself or herself and hold to a 
direction he or she sets 

» Feedback to team members: An individual's demonstrated ability to provide timely, 
appropriate, and accurate feedback lo team members 

■ Relations with functional managers: An assessment of the individual's ability to 
establish and maintain positive, constructive relationships with functional managers 

■ Standards of performance: The extent to which the individual clearly sets, maintains, 
and pursues high standards of performance 

■ Drive: The level of urgency expressed by the individual in pursuing work efforts 

■ Goal pressure: The extent to which an individual exerts pressure toward achieving 
goals; note that excessive goal pressure can also be a negative trait 




Key Competencies of a Successful Project Manager (cont.) 



■ Delegation (permissiveness): An individual's ability to assign work appropriately to 
subordinates or team members, within the context of providing a consistent amount of 
task direction and guidance; note that too much delegation without an appropriate 
amount of structure can be negative (permissiveness) 

■ Recognizing performance: An individual's demonstrated tendency to recognize the 
performance of team members in an appropriate manner 



Behaviors of a Successful Project Manager 



Is proactive 
Tries new ideas 
Perseveres 
Is goal oriented 
Communicates 
Motivates 
Is organized 
Prioritizes 

Is sensitive to people and 

situations 

Facilitates 

Coaches 

Is innovative 

Is honest 

Is realistic 

Provides critiques when required 



Listens 
Plans 

Thinks systematically 

Is assertive 

Is decisive 

Is self-confident 

is a team builder 

Pursues excellence 

Is enthusiastic 

Is energetic 

Delegates 

Is supportive 

Maintains contact 

Is sensitive to wants and needs 

Offers praise when appropriate 
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Types of Organizations Used in Projects 

Functional Projectized 





Matrix 

I 



1 




mm 
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How Organizational Structure Influences Projects 




Project Manager's 
Authority 



Little or none 



Limited 



Low to 
moderate 



Moderate to 
high 



High to 
almost total 



Percent of performing 
organization's 
personnel assigned 
full time to project 
work 



Virtually none 



0-25% 



15-60% 



50-95% 



85-100% 



Project Manager's 
role 



Part-time 



Part-time 



Full-time 



Full-time 



Full-time 



Common titles for 
project manager's 
role 



Project 
coordinator / 
project leader 



Project 
coordinator / 
project leader 



Project 
manager / 
project officer 



Project 
manager / 
program 
manager 



Project 
manager / 
program 
manager 



Project Management 
administrative staff 



Part-time 



Part-time 



Part-time 



Full-time 



Full-time 



From PMI Standards Committee 1996, 18 
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Projects in a Matrix Organization 



■ Matrix organizations evolved from the traditional management structure 

■ Its multidisciplinary team members are drawn from various line or 
functional units in a hierarchical organization 

■ Using a matrix, a project organization is superimposed on a functional 
organization 

■ Matrix organizations are complex and present a challenge to the project 
manager 

» Challenges involve: 

- Authority/responsibility of the project manager and functional 
manager 

- Communication flows {within the team and to and from other groups) 



Managing in the Matrix 



■ Successful operation depends on the attitudes, actions, and activities of 
the people involved 

■ A project charter, assigning responsibility and authority to the project 
manager, is extremely helpful 

■ Project managers and functional managers must develop good working 
relationships 

■ IBM project managers must realize that they accomplish their jobs 
primarily through the process of negotiation and leadership 

■ IBM project team members must adapt to a two-boss situation 





Project Organization: Survival Techniques 



■ Have a project charter 

■ Learn how to anticipate and constructively channel conflict 
i Establish a clear scope of project with team members 

■ Develop methods to promote teamwork 

• Document approval of objectives, plans, and budgets 

■ Reduce uncertainty and risk through careful and continual planning 

■ Plan globally, think locally 

■ Develop political awareness 

- Know the key players 

- Know their goals 

- Know your strengths and weaknesses 

- Know the influences 



Project Charter 



A project charter is a document that formally recognizes the 
existence of a project. It should Include: 

■ The business need that the project was undertaken to address 

■ A product description that documents the general characteristics of 
the product or service and draws a relationship between the service 
and business needs 



A project charter should be issued by a manager external to the 
project team and at a level appropriate to the needs of the project. It 
provides the project manager with the responsibility and the authority 
to apply organizational resources to project activities 



Basic Conccpts.pl Project Management - $21002 IBM Cutpwallon 



Project Charter Fundamentals 

» Establish the scope 

■ Be as concise as possible 

■ Names project manager as the responsible and authorized 
party 

■ Identify deliverables, schedule, budget 



Team Building Basics 



A team: 

■ Is a number of individuals associated in some joint action 

a Includes people in your organization, suppliers, and clients/project 
sponsors 

a Combines appropriate individual talents with a positive team spirit to 
achieve results 

Team development: 

■ Enhances the ability of stakeholders to contribute as individuals 

■ Enhances the ability of the team to function as a team 

When a group of individuals become a team, those individuals: 

■ Become committed to achieving common objectives 

■ Learn to work well together and enjoy it 

■ Produce high-quality results 
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How Do You Build a Team? 



Select the right team members 

- Identify the project skills needed 

- Validate required skills and resources 
Organize the team 

- Identify all subproject managers 

- Prepare organization chart 

- Establish delegation levels 
Ensure open communication 

- Establish communication plan 
Inspire team members to do their best 

Incorporate new team members as they join the project during its life 
cycle 



Considerations For a Multicultural Team 



■ Social customs 

■ Time zone differences 

■ English as a second language 

■ Protocol practices & communication patterns 

■ Documentation practices 
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Team Charter 



Sets broad performance objectives 

Joining the team implies its acceptance 

Sets expectations for the success of the project 

Sets the roles and responsibilities for the project team 

members 

Sets the ground rules for the operation of the project team, 
including: 

- Administration guidelines 

- Conflict management 

- Escalation 
Communication 
Status reporting 

Feedback from higher level meetings 
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components ot a Useful Team Charter 




Team performance objectives 




■ Mutually agreed on 




■ Signature of team member 




Expectations of team members 




■ Behaviors 




■ Timeliness 




■ Respect 




\ ■ Commitment 




8 Openness 




Rules of engagement 




■ Meeting protocols 




■ Decision making 




■ Discussion protocols 




■ Support of agreements 
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Components of a Useful Team Charter (continued) 



Administrative procedures 

■ Communication management 

■ Document control 

■ Point of contact 

■ Escalation procedure 

■ Work hours (including overtime) 
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Key Messages for Module 2 



■ The project manager is the focal point - the person responsible 
for the success of the project ; he or she may or may not be 
involved at the start of the project 

» The project manager must: 

- Learn lo maximize the benefits of any organizational 
structure used 

- Motivate a team to enhance its ability to function 

- Develop a political awareness- with in IBM and with 
clients/project sponsors, suppliers, and other stakeholders 

■ A project charter gives the project manager the responsibility 
and the authority to apply organizational resources to project 
activities 

■ A team charter sets both broad performance objectives for the 
team and expectations for the project; performance objectives 
should be measurable 
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Module II Team Exercise: 
Team Charter 





Module II - Team Exercise 

Team Member Roles and Responsibilities 



Each team member is to select one of the roles of designer, 
developer, integration specialist, training coordinator or 
deployment coordinator 

The project manager role will rotate around the team so each 
team member experiences the role of PM during a part of the 
study 

If you feel that there are roles and responsibilities that the case 
study does not supply, then identify them as part of the exercise 
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Module II - Team Exercise 
Creating an organized Team 



You have just joined the Gymnastics Results Management 
System (RMS) team. Your group is meeting to kick off the 
project. 

As a group, you have been asked to prepare organizational 
ground rules and develop the team administrative requirements 
and administrative responsibilities, and define the procedural 
guidelines that will govern the behavior of the team. 
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Module II - Team Exercise 

Organizational Ground Rules - more suggested topics 



Time limit for discussion 

Decision-making process 

How to handle conflicts 

How long team works; into lunch, after hours 

How team deals with internal issues; for example, dominant or 

quiet team members 

Assign PM and backup for each module 

Assign roles and responsibilities 

Develop a team name 

Remember that you will work with foreigners 
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Module III: 

Identifying and Validating Requirements 
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Objectives 



At the end of this module, you should be able to: 

■ Recognize the need to identify and validate requirements 

a Recognize pitfalls in defining requirements 

» Recognize the client/project sponsor's role in identifying 
requirements 

■ Describe how to prepare a baseline 

■ Prepare a project definition report (PDR) or scope definition 
document for effective project planning 
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Baseline and Exclusion Definitions 



Requirements 





■ Needs: Client/project sponsor requests, ideas, and business requirements 

■ Requirements: Statements of desire for a future system 

■ Exclusions: Statements of "not-included" for a future system 

■ Baseline: Statements of commitment for future system 
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Why Establish a Baseline ? 



The Baseline: 

■ Incorporates the original requirements for a project plus or minus 
approved changes 

■ Serves as the basis for managing requirements 

■ Must be signed and approved 

■ Helps serve as the basis of ensuring that the project is complete 
<• Defines the scope of the project 



" Basic Concepts ol Project Management 



©J0Q2 l3fvtcVpo;a!k)n'' " 



Baseline = Requirements - Exclusion 




Fundamental Questions in Identifying Requirements 



IPD and CRM issues 

a What should it do? 

a Who are the stakeholders? 

■ How much will it cost? 

■ What is the expense plan? 

« How long is the development process? 

■ How will it be serviced/maintained and what are the warranty 
implications? 

■ Can the existing infrastructure support it? 

■ What outside support is required? 
» How will success be defined? 

a What support system will keep it in place? 
IPD issues 

a How will it be marketed? 

■ What is the channel strategy? 

■ How will it be ordered? 

■ How long will it last? 

■ Are similar products already in development or operation? 
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Guidelines for Identifying and Validating Requirements 



® Work jointly with clients/project sponsors 

■ Obtain detailed descriptions of problems 

a State the requirements explicitly and have project staff and 
clients/project sponsors sign off 

■ Be realistic; assume that if a requirement can be misinterpreted, it will 
be misinterpreted 

■ Use a project definition report 

■ If possible, include pictures, graphics, models, and other nonverbal 
exhibits in requirements formulation 

■ Ensure that project deliverables are directly related to requirements 

■ Establish a system to monitor changes made to the requirements 

■ Educate project staff and clients/project sponsors about problems in 
specifying requirements 

■ Obtain client/project sponsor signature on requirements baseline 
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Establishing a Baseline (continued) 

Change management helps update the current baseline 



Needs 





Evaluation of 
Change 









Requirements 



Current Baseline 




Approved 
Change 



*» New Baseline 





Baseline N 




Baseline N+1 




Baseline N+2 
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Using the Project Definition Report to Identify and 
validate Project Requirements 

a Creates a baseline for measuring and managing change 

■ Sets measurement criteria, helps control the project 
<■ Prevents team from jumping in and wasting effort 

■ Ensures clarity of scope before detail planning begins 
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What Is the Project Definition Report 



■ Is an overview document 

■ Sets project bounds 

■ Establishes what project will and will not do 

■ Begins to organize project into manageable form 

■ Is not a project charter 

■ Is not a team charter 

■ Is not a customer contract 

Note: The project definition report is also known as the 
scope definition document 
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Components of a Project Definition Report 

a Background and summary of project 

- Where did this project come from? 

- Why is it being done? 

- What does the customer receive or not receive by project 
end? 

■ Project objective(s) 

- What is the target of the project? 

- What problem should the project solve? 

- What are the major components of work on the project? 



Project deliverables 

- What are the major products required to meet the 
objectives? 

Customer deliverables 
*- Project deliverables 
>■ Process deliverables 



Components of a Project Definition Report (continued) 



■ Key milestones 

- What major points in time are important to communicate? 

- What major points in time are important to measure against? 

- What are the bureaucratic milestones? 

■ Assumptions 

- What unknowns are being made into knowns? 

- What are the operating rules and standards? 

■ Risks 

- What obstacles could jeopardize project success? 
>■ Cost 

Schedule 
> Requirements 
>* Quality 

>- Customer satisfaction 
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Components of a Project Definition Report (continued) 

■ Key resource requirements 

- What specialized resources are necessary to complete this 
project? 

>■ Staff 

Material 
>■ Facilities 

■ Constraints 

- What issues are restricting this project? 
>■ Technology 

> Staff 
>- Political 

■ Interrelated projects 

- What effects are there on other programs? 

- What other projects are addressing related issues? 
- What other projects have a potential impact on this project? 



Components of a Project Definition Report (continued) 

» Acceptance criteria 

- What technical performance is required? 

- What checkpoints are in place to ensure that the right 
product is being delivered in the right way? 

- How will success be measured? 



■ Signatures 

- What reviews will be done? 

- Who approves project reviews? 



Reviews 

- At what points will management reviews be conducted? For 
what purpose? 

- At what points will customer reviews be conducted? For what 
purpose? 

- At what points will informal (team, peer) reviews be 
conducted? For what purpose? 



Sasfe Concents oi Project Management 



'■• tB 2002 IBM Corpora \h:\ ' 




Components of a Project Definition Report (continued) 



Communication plan 

- How will team members communicate? 

- How will the team communicate with the customer, stakeholders, and 
IBM management? 

- What types of meetings will be held? Frequency? Purpose? 

- What types of reports will be written? Frequency? Purpose? 

Change management plan 

- What process will be followed when project change occurs? 
Financial Analysis 

- How will the project manager control budget and cost? 
References 

- Documents with title, date, and version that affect the scope 
definition 



Pitfalls in Defining Baselines 



Dealing with inherently unclear requirements 

- Dynamic nature of requirements 

- Uncertainty regarding who will use the product (important for 
CRM, critical for IPD) 

Identifying solutions prematurely 

Addressing the requirements of multiple clients/project sponsors 
Developers' values may color and distort requirements 
Selective filtering of requirements 
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Key Messages for Module 3 



Always do requirements identification, analysis, and validation 
Ensure that you ask the right questions to understand where 
your project fits in management's business strategy 
Use a systematic approach 

State requirements explicitly - have project staff and the 
client/project sponsor sign off 

Consider requirements definition between the project team and 
client/project sponsor 

Know the differences among requirements, exclusions, and 
baselines 

Issues will occur that require management and resolution and 
may result in change 

Baselines are essential to controlling the evolution of 
requirements 

As the project manager, assume responsibility for screening 
change requests, avoiding scope creep, and revising the 
baseline 
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Module III Team Exercise: 
Requirements Baseline 
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Module III - Team Exercise 
Creating the Requirements Baseline 








■ Read the case study 

■ As a group and in your chosen role: 

■ Identify the requirements 

■ Identify the exclusions 

■ Determine the baseline 

■ Document assumptions 
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Module II! - Team Exercise 
Deliverables by Group Assignement 



B Group 1 - 1 , 8 & 9 

■ Group 2 - 2, 3, & 4 

■ Group 3 - 5, 6 & 14* 

■ Group 4- 10, 11 & 12 
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Module IV: 

Organizing the Work (Work Breakdown Structure) 





Objectives 



At the end of this module, you should be able to: 

■ Describe the use of a work breakdown structure (WBS) in 
project planning 

■ Explain the value of a WBS 

■ Develop a WBS 

■ Use a WBS to structure the work to build deliverables 





WBS Definition 



WBS An Activity - oriented structure of the work to be done. Systematically 
presents all the work on the project that affects cost, schedule, or specifications. 



PBS Level 



XYZ Product Development Project 
Deliverable 1 : Hardware Components 
1 . 1 Procedure hardware components 

1 .1 .1 From HDW Development Team 

1 .1 .1 .1 Identify members 

1 .1 .1 .2 Schedule kickoff meetini WBS Level 

1 .1 .1 .3 Conduct meeting 

1.1.2 Develop Initial HDW dev. plan 



Deliverable 2: Software components 
2.1 Produce software components 

2.1 .1 From SFW Development Team 

2.1.1.1 Identify members 

2.1 .1 .2 Schedule kickoff meeting 
2.1 .1 3 Conduct meeting 

2.1.2 Develop Initial SFW dev. plan 



I 




and so on ... 
.work pkg level 



The size and number of WBS levels vary it each project, but the WBS must 
be completed to relate all elements to one another and to the total project 



a 
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Why Is a WBS Needed 



Is the dominant prerequisite for successfully integrating and 
controlling the total project by assisting in: 

- Developing the risk management plan 

- Completing the schedule 

- Developing the cost estimate 
Focuses attention on project objectives 

Provides a framework to identify development projects 
separately from geographies, accounting systems, funding 
sources, and so on 

Clarifies responsibilities 

Encourages detailed planning and documentation 

Identifies specific work packages for estimating and assigning 

work 

Helps build the project team 
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Uses of a WBS 

Integration Strategy 






Risk Planning 




Status Reporting Co8f Estimat | on Development Project Schedule Change Mgmt 
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Characteristics of WBS Work Packages 

■ Each work package results in a deliverable 

- External - given to client/project sponsor 

- Internal - used by the project (sometimes called a work product) 

a Deliver a distinct, identifiable product or result 

■ Have definitive, verifiable completion criteria 

■ Can be clearly assigned as the sole responsibility of a single 
organizational unit or individual 

* Show what work will be done 
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Guidelines for Developing a WBS 



1 . Gather all project-related materials 
Scope definition 

Technical proposals, supplier/subcontractor proposals, and so on 

2. Review WBSs used for similar project 

3. Prepare a summary high-level WBS; create it down to the level of 
manageable and trackable work package 

4. Develop the WBS to the lowest possible level of control 

5. Involve responsible project team members in developing the 
WBS 

6. Include project support tasks such as project management and 
quality assurance 

7. Avoid developing detail before it is needed 

8. Review the WBS with responsible project stakeholders (internal 
and external); get buy-in from those responsible for each work 
product/element 

9. Add appropriate work packages to manage risks 

1 0. Prepare a WBS dictionary 
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Contents of a WBS Dictionary 



■ Work package number 

■ Work package title 

■ Description of work 

■ Work to be accomplished 

■ Deliverable/objective 

- How do you know you are finished? 

- Who needs the output? 

■ Ownership/participation 

- Who is responsible? 

- Who else will be involved? 

■ Acceptance criteria 



Questions to Consider in WBS Development 



How will it be maintained? 

- Normal revisions 

- Change management 

How will it be stored and distributed? 

Will a project planning tool be used and, if so, how will that 

affect WBS creation and maintenance? 

How will you handle level of effort work? 

Are the project management elements complete? 

Can responsibility be assigned to an individual or 

organizational unit? 

Is there buy-in from the individuals or organizations who will 
be responsible for the work element? 

Is the unit of work verifiable? - can acceptance criteria be 
defined? 

Can progress be monitored? 
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Key Points on a WBS 



■ Identify all tasks to accomplish the project 

■ Use good judgment as the key to an effective WBS - no hard 
and fast rules 

■ Structure the WBS as information will be used 

■ Use levels of detail that allow for realistic estimating 



■ Use levels of detail that allow assignment to a single 
organizational control unit 



- Baste, Concepts ot Projoct Management 



IBM Co/pofaliqir- 



Key Points on a WBS (continued) 



■ Limit level of detail to level of control 

* Each lowest level task should result in a deliverable 

■ Each WBS description should include an action verb, for 
example: 

- Establish manufacturability criteria 

- Prepare final product proposal package 

- Update common software 

■ Each task should have a single, identifiable owner assigned 
after the WBS is done 
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Key Messages for Module 4 

■ WBS definition: An activity-oriented structure of the work to 
be done. 

■ Systematically presents all the work on the project affecting 
cost, schedule, or specifications. 

■ Deliverables can be internal or external 

■ The WBS serves as the framework on which the project is 
built and as the "map" for executing the project 

■ The WBS focuses attention on project objectives, 
encourages detailed planning and documentation, clarifies 
responsibilities, and identifies specific work packages for 
estimating and assigning work 

■ The WBS is used throughout the project; if the project plan is 
to be revised, the WBS must be revised as well 

■ Prepare a WBS dictionary to provide detailed background on 
each work element in the WBS 

■ Remember: The WBS is the cornerstone of quality project 
planning; it is a tool, not an end unto itself! 



WBS Definition 



IBM 

Activity 
Verbs 



Identifies work 
required to create 

a deliverable 



PMI 



Deliverable 



Nouns 



Identifies the output 
of the work 
(deliverable) 
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Module IV Team Exercise: 

Creating Hierarchical Decomposition Structures 
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Module IV - Team Exercise 

Creating Hierarchical Decomposition Structures 



Read the case study 

Review any previous documents to identify all major product 
deliverables for your project 

Using this information, create a WBS for oniv your 2 or 3 
subproiect deliverables 

After this is created, review the WBS as a team to ensure its 
completenes 

Be thorough, but do not go below three levels of module-level detail. Remember to approach this from 
the perspective of the role you're playing. Be prepared to present the WBS to the class. 
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Module IV - Team Exercise 

Creating Hierarchical Decomposition Structures 



■ Use easel pages to draw and show the decomposition diagram 

■ Write the WBS number and WBS name in every box 

■ Use "noun" and "verb" test to help with proper context 

■ Draw lines 

■ PM presents the team process and high-level structure 
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Module V: 

Developing a Risk Management Plan 
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Objectives 



At the end of this module, you should be able to: 

■ Define risk management 

■ Discuss the reasons for risk management in project 
management 

a Describe the risk management process 

- Use risk identification methods 

- Use risk evaluation methods 

- Use risk mitigation methods 

- Use risk monitoring methods 
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What is Risk? 



Risk has three components: 

■ An event 

■ Probability of the occurrence of that event 

■ Impact of that event (or amount at stake) 

A risk event is a possible undesirable event or an unplanned 
opportunity. Risk could result in the project's not meeting one or more 
of its objectives. 

PMBOK defines risk events as discrete occurrences that may effect 
the project for better or worse 

Note: All projects have risk. If risks are ignored, you have increased 
the likelihood that the project will fail in some way or will be less 
successful. 
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Types of Risk 



® Business vs. pure 

- Business risk: Normal risk of doing business with 
opportunity for gain or loss 

- Pure risk: Risk that presents an opportunity for loss only 

• Known vs. unknown 

- Known: Risk we can anticipate 

- Unknown: Risk not planned for and not recognized 
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Risk Management 



An ongoing iterative process concerned with identifying, 
evaluating, mitigating, and monitoring risk throughout the project 

An integral part of project management 

A series of forward-looking, linked activities and processes that 
is designed to handle risk and reduce their probability or impact 
on the project 
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Risk Management Process 



IBM 

» Identification 

• Evaluation 
® Mitigation 

• Monitoring 



PMI 

• Identification 

• Quantification 

• Response 
Development 

• Response Control 
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Risk Management Process 

CRM 



PMBOK 
IPO 



Solution Design 


Solution Delivery 


Concept 


Develop 


Execute 


Finish 


Concept 


Plan 


Develop 
Qualify 


Close 


Risk Identifier 


ition 


Risk Identific 


ation 


Risk Evaluation 


Risk Evaluation 


Risk Mitigation 


Risk Mitigation 




Risk Monitoring 



Life Cycle 
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Risk Management Process 



CRM 
PMBOK 

IPD 



Solution Design 



Concept 



Concept 



Risk Identification 



Develop 



Plan 



Risk Evaluation 



Risk Mitigation 



The Risk Management process 
is repeated several times until 
an acceptable overall risk plan is 
achieved through applied mitigation 
strategies 



Solution Delivery 



Execute 



Develop 
Qualify 



Risk Identification 



Finish 



Launch 



Risk Evaluation 



Risk Mitigation 



Risk Monitoring 



Life Cycle 
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Why Risk Management 

■ Protect 

- Cost 

- Schedule 

- Specifications 

■ Prevent surprises 

■ Focus on building the right offering the first time 

■ Prevent management by crisis 

■ Prevent problems from occurring or, if they do occur, from escalating 

Specifications 




Risk Management Has Four Major Step 

i 




Note : Mitigation means to make less severe 
1 
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The Project Manager's Role in Risk Management 

a Identifying and understanding risk events 
" Planning to handle risk events 
a Incorporating risk management into the project 
management planning process 

- Using the right strategies (for example, containment or 
contingency) to fit the situation 

a Monitoring risk events on a regular basis 

■ 1 Reassessing risk events after each risk events 
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Step 1 in Managing Risk: Identifying Risk Events 




SH3 



Input 

• WBS 

• Contractual requirements (statement of 
work) 

• Field and marketing information 

• Product plan assumption 

• Earned value data 
» Offerings portfolio 

« Lessons-learned files 

» Company objectives and plans 

• Other project-related plans 

• Schedule 

• Review reports 



Techniques 

« IBM risk criteria and questionnaires 

• Previous project lessons learned 

• Idea-generation techniques 

- Expert interviews 

- Brainstorming 

- Nominal group technique (NGT) 

Identify risk events 

• Early 

• Often 

• Regularly 

• At all levels 
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Consider Stakeholder Objectives in Risk Management 




Sales 




Business Manager 




Project Manager 

Project 
Objectives by 
Stakeholder 




Supplier 
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Finance 



Client/project 
sponsor 
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Sample List of Identified Risk Events 



RIN* 


Source of 
Risk 


Risk Event Probability 


Impact Severity Rank 


1 




Incomnlpto UHn Anali/QiQ 

results in user interface 
problem 




2 




Insufficient time to perform 
product verification test 




3 




elements noi tuny iniegratea 
into OS public build 




4 




No test suites available for 
required open systems 
standards 




5 




Use of new IPD 
methodology will delay 
schedule 


* Risk identification number 
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Step 2 in Managing Risk: Evaluating Risk 



Analyzing 

■ Determine: 

- Probability of occurrences 

- Impact of occurrence 

- Severity of risk (Severity = Probability and Impact) 

Prioritizing 

■ Rank risks by severity 

■ Decide which risk are worthy of attention 

Evaluating risk reduces event outcome uncertainty 
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Practical Approach for Analyzing Risk 



Estimate the probability and impact for each identified risk 
event 

- Quantify where possible 

- Quantify when necessary 

- Combination of both helps determine its final importance 
Identify worst, best, and most probable scenarios 



Assign risk analysis tasks to appropriate team members 
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Questions to Consider in Evaluating Risk 



■ Precedence: Has the risk event occurred before? 

■ Familiarity of the operation: Has the work been done before? 

■ Skills: Does the staff have the ability to do the work? 

■ Resources: Are there adequate materials to complete the work? 

■ Time: Is there enough time to complete the work? 

■ Quality: Is there confidence about the quality of work required? 

■ Cost: Is there sufficient funding to complete the work? 



Quantitative Risk Rating System for Individual Risks 



« Uses probability concepts - the likelihood that an event will 
occur or will not occur 

• Basic rules of probability must be followed, for example, as 
in statement: 

"There is a low probability that the integration test phase will 
be delayed by three weeks." 



Severity Risk Rating System for Individual Ris 





High 



Likely to cause significant serious disruption to 
schedule, increase in cost, or degradation of 
performance 



Medium 



Has potential to cause some disruption of 
schedule, increase in cost, or degradation of 
performance 



Low 



Has little potential to cause disruption of schedule, 
increase in cost, or degradation of performance 



Sample Severity Matrix 



Impact 



Probability 









■ 


High 


Medium 


High 


Unacceptable 


Medium 


Low 


Medium 


High 


Low 


Low 


Low 


Medium 
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Sample List of Identified Risk Events * Risk identification number 



Risk Id # Source of 
Risk 



Risk Event 



Probability impact Severity 



Incomplete UCD analysis 
results in user interface 
problem 



Low 



Medium 



Insufficient time to perform 
product verification test 



High 



Medium (Users 

reject system-2 
month to test) 



3 
4 



Elements not fully integrated Low 
into OS public build 

No test suites available for Medium 

required open systems 

standards 



Low ($5,000 and 
1-week delay in 
time to market) 

Medium (6-week 
delay in verification) 



Use of new IPD 
methodology will delay 
schedule 
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Low probability 
based on past 
project 



Low ($20,000 for 
training add 2 
weeks to schedule) 
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Practical Approach for Prioritizing Risk 

■ Group risk events by severity (group=high, medium, low) 
* Rank analyzed risk events from highest to lowest 

■ separately rank risk events with similar severity 

■ Confer with team members to prioritize risk events 

■ Do not plan mitigation strategies as a part of this process 
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Sample List of Identified Risk Events 



Risk Id # 



Source of 
Risk 



Risk Event 



Probability Impact Severity Rank 



Incomplete UCD analysis 
results in user interface 
problem 



Low 



Medium 



Medium 3 



Insufficient time to perform 
product verification test 



High 



Medium (Users 

reject system-2 
month to test) 



High 



Elements not fully integrated Low 
into OS public build 

No test suites available for Medium 

required open systems 

standards 



Low ($5,000 and Low 5 
1 -week delay in 
(ime to market ) 

Medium (6-week Medium 2 
delay in verification) 



Use of new IPD 
methodology will delay 
schedule 



Low probability Low ($20,000 for Low 
based on past training add 2 
project weeks to schedule) 
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Step 3 in Managing Risk: Mitigating Risk 



Risk mitigation involves: 

■ Assigning actions and strategies to contain, reduce, or eliminate risk 
events 

The risk mitigation process includes: 

■ Establishing mitigation options 
* Developing an action plan 

■ Reviewing the mitigation process 
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Practical Approach for Planning Strategies to Mitigate Risk 

■ Work down prioritized risk listing 

■ Identify various mitigation alternatives 

■ Evaluate alternatives and select a primary option 

■ Incorporate options into risk management/project plan (assign an 
owner) 



Strategies to respond to Risk 



Avoid 

Ignore/Accept 



I am aware of this risk and I do not choose this option 

I am aware of this risk and I am willing to accept the 
consequences should the risk event occur 



Contain 



Establish 
contingency 



I am aware of this risk and I will take specific action to 
minimize its occurrence and effect 

I am setting aside funds to be used when the risk occurs or 
when later containment is deemed to be appropriate 



Transfer 



I am aware of the risk, and I will transfer a portion of it 
to another party 
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Containment vs. Contingency 



Containment 

■ Tasks are added to WBS 

■ Eliminates or reduces specific risk 

■ Lowers the level of overall project 
risk 

■ Is estimated, scheduled, costed, 
and priced 



Contingency 

■ Funds held in separate account for 
future use 

>■ Approach 1 -overall 

• Reflects overall risk to the 
project 

• Is based on a percentage of 
the overall cost of the project 

>■ Approach 2-specific 

• Reflects a specific risk to the 
project 

• Is based on specific cost 
should the risk occur 

• May be less than the sum of 
containment (not all risk will 
occur) 



Multiple Factors Affects Selection of Risk Mitigation 
Strategies 



Project phase and application 

Size 

Priority 

Complexity 

Expense 

Time available 

Cost of technique 

Required level of detail 

Ease of use 

Resource availability 

Project manager and upper manager's commitment 
Customer satisfaction 



Note: There are many issues over which the project manager has 
little or no control. For example, the project manager does not control 
new laws, customer mergers, or team members who quit. 
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Sample Risk Management Plan 



Rank 


Risk 
Id* 


Source Of 
Risk 


Risk Event 


Mitigation Actions 


Action 
Required 


1 


2 


Architect 
review 


Insufficient time to 
perform product 
verification test 



• Work available personal overtime 

• Plan activities 

• Negotiate with client/project sponsor for 
more time 




2 


4 


WBS review 
by test lead 


No test suites 
available for required 
open systems 
standards 


• Hire testing firm to validate open 
system standards 




3 


1 


WBS 


Incomplete UCD 
analysis results in 
user interface 
problems 


• Use Joint Application Design <JAD) to 
determine initial requirements 

• Use task analysis to better understand 
potential client/project sponsor's environment 

• Build prototype 




4 


5 


Contractual 

Requiremen 

ts/ 

product plan 


Use of new 
methodology will 
delay schedule 


• Cancel annual leave, send staff to training 

• Hire outside expert to act as coach 

• Use on the job training approach give 

everyone the material and tell them they must 
know ft by a certain date 




5 


3 


Company 
objectives 
and plans 


Elements not fully 
integrated into OS 
public build 


• Create OS development SWAT team to 

complete all necessary items quickly 

• Negotiate with senior management for more 
time 





Review Risk Management Plan 



■ Review with project team 
a Obtain buy-in on the plan 

■ Get an independent review of the mitigation strategies, looking for: 

- Things you may have missed 

- Validation of your strategies 

- Possible alternatives to your strategies 
a Update all related documentation 

Make sure risk is made visible: 

■ In initial project review 

■ With client/project sponsor (unless it's a risk we can control) 

■ To management 




Step 4 In Managing Risk: Monitoring Risk 



■ Implement and track risk management plan 

■ Communicate the plan's status to project team members and other 
stakeholders 

- Continually document events and actions taken 

■ Create a lessons learned database 

After risk are evaluated and actions assigned, the risk must be 
monitored and managed 



Risk Management Is a Continuous Process 



» After the risk management plan is prepared, continue to: 

■ Identify new risk, which may result from: 

- Changes in clienVproject sponsor, technology, organization, 
resources 

- Resurfacing of old risk 

- Time 

■ Evaluate previously identified risks 

- Still possible? 

- Same probability and impact? 

■ Mitigate 

- Is mitigation still appropriate? 

- Are actions required for this strategy? 

- Are backup strategies appropriate? 

■ Document 

- Continuously keep current, accurate, complete, and simple 

■ Communicate 



Basic Concepts ot Project Mon 



© 2002 I BM Oworalion" 



Key Messages for Module 5 

■ Risk management is a continuos process 

a Risk management is an essential element of a project plan 

■ The risk management plan should be reviewed with the project team on 
a regularly scheduled basis 

■ Stakeholder's views of risk differ 



Risk can be managed 
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Module V Team Exercise: 
Creating a Risk Management Plan 





Module V - Team Exercise 
Creating a Risk Management Plan 



Identify the top 5 or 7 risks events that might be present in this 
project for each of vour assigned 2 o 3 subproiects (14 or 15 
risks total) 

Continue the risk management process by preparing a risk 
management plan that includes evaluation and risk response 
strategies 

Develop a Risk Action for the top 2 or 3 risks for each 
subproiect (6 risks total) 
Add your Risk Actions (tasks) into your WBS 
Prepare to brief the project sponsor 
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Module VI: 

Establishing a Project Estimate 
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Objectives 



At the end of this module, you should be able to: 

■ Define an estimate 

■ Determine what to estimate 

■ Generate an estimate 

■ Recognize the difference between effort and duration 

■ Describe specific types and methods of estimating 

■ Discuss the estimating process 

■ Validate an estimate 
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What Are You Estimating ? 



a Resources 

- Staff 

- Facilities 

- Material 

■ Cost 

- Direct 

- Indirect 



■ Duration 
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Before You Estimate the Number of People .., 



Level of Effort 

Tools 

Hardware 

Specialty Skills (e.g. security) 

Facilities 

Travel & Living 

Training 

Suppliers 

Infrastructure (e.g. networks) 



Gifts (e.g. recognition) 

Shipping 

Royalties 

Risk Contingencies 

Value Added Tax 

Licenses 

Vendors/subs 

Insurance 

Admin. Costs 

Other Division Expense 
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Level of Effort Work 



■ Support type activity 

■ Does not lead directly to discrete measurement 

a Uniform rate of activity over a specific period of time 

■ E.g., project management, communication, administrative (timekeeping), 
etc. 
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Estimating 

Estimating is the process of determining 
effort 
AND / OR 
duration 

for the elements in the work breakdown structure (WBS) 

Some fundamental definitions must be understood 
in order to perform this. 
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Estimating - Considerations and Definitions 



» Start Effort: time required to complete task 
(usually measured in staff hours: person-hours) 

■ Working time: time available for work 

(usually measured in working hours/day, working days/week, and so 
on) 

■ Calendar time (elapsed time): time required to perform the effort 
considering the working time (usually measured in calendar days, 
calendar weeks, calendar months) 

Examples: 

■ It takes 24 staff hours to convert the presentation charts 

- Our staff person works 6 hours a day (working time) 

- How many working days to complete ? 24/6 = 4 working days 

- Starting on Thursday, 6 calendar days (counting the weekend and 
no holidays) 

Another example: 

■ Some task as above 

- We have two staff persons also working 6 hours a day (working 
time) 

- They can complete the work in 24 / (6 * 2) = 2 working days 

- Starting on Thursday, it only takes 2 calendar days 
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Estimating - More Considerations and Definitions 



■ Availability: Staff person available and able (willing) to work 

- usually measured in working hours per day 

- working days (not vacations, not other work) 

■ Productivity: relative measure of work in a time unit 

- Person A can do the work in 9 hours, person B in 6 hours 
Which person's productivity was used for the estimate ? 

Was the estimate accurate enough to apply a productivity factor ? 
or is that just a 'number game' ? ... 

- Rarely, only rarely, are estimates good enough to use with 
'productivity factors' 

Example: 

■ It takes 24 staff hours to convert the presentation charts (person B 
skills) 

- Instead we get a person with the assumed lower productivity (6 / 
9 = 0.67) 

- Our staff person still works 6 hours a day (working time) 

- How many working days to complete ? (24 / 6) / 0.67 = 6 working 
days 

- ... and so on... 



Utilization Factor 



Utilization factor: Amount of time that a full-time equivalent (FTE) can be 
used for the length of a project 

Hours available/year = 2,080 {52 weeks x 5 days x 8 hours) 
Example: 



Education 

Vacation and holidays 

Administration 

Personal 

Other (travel, sickness) 



80 hours 
160 hours 
80 hours 
90 hours 
70 hours 



Total nonproject hours 



480 hours 



Total project hours (2,080 - 480) 

1 ,600 / 2,080 

1,600/12 



1,600 hour 
77% utilization 
134 hours/month 
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Example of Utilization Guidelines 







Utilization 


Project Length 


Hours / Month 


(Approx. Percentage) 


3-6 month 


176 


> 80 % 


6-12 month 


130-140 


75-80 


> 12 month 


120-130 


70-75 


Note: 1 76 hours / month = 22 workdays (8-hour days) 


The shorter the length of the project, the higher the utilization 




Estimating Task Duration Using Utilization Factor 



■ Assumption 

- Utilization factor of 80% 

- Estimated effort for the task is 40 hours 

■ Duration = Estimated effort / utilization factor 

■ Duration in hours 

- Duration = ((40 hours / 0.8) / *8 hr/day) 

- Duration = 50 hours / 8hr/day =6.25 days 



*8 hr/day = Utilization Rate 
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Estimating 



Note: 

■ If the work is repeatable AND enough measurements of different 
groups are available, THEN we may obtain reliable and accurate 
productivity factors 

■ Contiguous duration: Work time that is not or might not be interrupted 

■ Interruptible duration: Work time that may be interrupted 

■ Level of effort: Activities necessary to support a project; difficult to 
measure in terms of discrete accomplishment and characterized by a 
uniform rate of activity 

Special Cases: 

■ Level of effort (LOE): Activities of support type or activities which 
cannot be scheduled. Difficult to measure in term of discrete 
accomplishment and characterized by an overall effort. 

- For scheduling and resource-loading reasons, this may be spread 
evenly over appropriate periods 
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Estimating 



Estimates: 

■ Effort 

- Usually measured in staff 

When number of staff and their working time and / or availability is 
taken into account, the duration in working days may be 
calculated. 

An 'average' productivity is assumed, 
(avoid fancy 'productivity' number games) 

■ LOE 

- Usually measured in staff hours for the duration of the activity, 
resulting in an average load (e.g. 2 hours /week) 

a Duration 

- Usually measured in working days 

Used for fixed duration activities or simpler estimates 
(e. g. it will take 2 working days ) 

■ When scheduling, specific resource availability and productivity may 
effect actual duration 
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What is an Estimate ? 



■ An assessment of the likely quantitative result 

■ Usually applied to project cost factors and to WBS 

■ Should include some indication of accuracy for example, + - n 
percent 

■ Usually used with a modifier, for example, preliminary, conceptual, 
feasibility 

Estimating is not: 

■ An account strategy 

■ Pricing 

■ Investment marketing 

■ Client/project sponsor satisfaction 
- Software or tools 

■ Finding the fastest way 

■ A Budget 
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Reasons For Estimating 



To evaluate a project's estimated costs before authorizing 
implementation 

To provide a basis for tracking and managing project expenditures using 
activity-based costing or other methods 

To establish a managerial baseline against which to measure actual 
expenditures 

To provide the project manager with a tool for evaluating routine project 
decisions 

To provide fact-based information to support investment analysis 
To establish resources required and the resulting schedule 
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When Do You Estimate ? 

■ After the WBS is developed 

■ When determining whether to bid an opportunity 

■ Before you take over a project 

» When you move into the next phase of the project 

■ Whenever the WBS changes 

■ Whenever there are authorized changes in resources, materials, 
services, and so on 
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Estimating Process 



Establish 
estimating 
objectives 



Determine 
Project details 



Select 
appropriate 
model 



Develop 
estimating 
strategy and plan 
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Baseline 
estimate 



Use estimate 
in project plan 





Prepare 
estimate 




i 




Include 
Risk 








Validate and 
finalize 
estimate 


i 
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Fundamental Questions for Estimating 



Who or what do we need ? 

Who or what can do the work ? 

Who or what can we get ? 

What level of competence is essential ? 

How long will each work package take ? 

How will we use the resources ? 

How will they affect schedules and costs ? 

How much effort will project management activities take ? 
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Methods of Estimating 



■ Guess 

■ Supplier 

" Parametric 

■ Analogy/comparison 

■ Expert judgment 



TYPE 


ACCURACY 


USE 


MPTunn 
■vie i nuu 


Order of 
magnitude 


-25%/ +75% 


Initial, 

Concept, 

Entry 


Analogy/comparison 

Parametric 

Guess 


Budget 


-10%/ +25% 


Concept 
DCP 

CRM-RFI 
Preliminary 
Response to RFP 


Analogy/comparison 
Parametric 
Expert judgment 


Definitive 


-5%/ +10% 


Plan DCP, 
CMR - 
Proposal 


Analogy/comparison 
Parametric 
Expert judgment 
Supplier 
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Parametric Estimate 



Specific measures used to estimate the effort required to complete a 
particular task or produce a particular work product, for example, dollars 
per square foot, hours per number of lines of code, dollars per gallon, or 
dollars per function point 
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Analogy / Comparison Estimating 



Evaluate 
project 



Find 
comparable 
project 



Assess 
comparable 
quality 



Evaluate cost 
of previous 
project 



Apply to new 
project 
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Guidelines for Estimating 



Estimate effort based on average skill 
Estimate duration based on utilization rate 

Calculate cost based on assumed labor rate to obtain the cost estimate 



Expert Judgment Estimates 



■ Used to assess input to the estimating process 

■ Expertise is provided by any group or individual with specialized 
knowledge or training 
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Approaches to Arrive at Estimate 



Top-down 

■ High-level estimate of projects or their summary task based on 
parametric, analogy / comparison, or expert judgment 

■ Estimated based on collecting judgments and past experiences and 
on evaluating past data concerning similar activities 

■ Considered generally to be less costly and less accurate than other 
techniques 

Bottom-up 

■ Estimating the effort of individual work items in hours 

■ Then summarizing or rolling up the individual work items to get a 
project total 

■ Cost and accuracy driven by the size of the individual work items 
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Sequence for estimating 



The correct sequence to follow when estimating is: 

1. Estimate effort 

2. Based on utilization rate, get the duration 

3. Assume skill level 

4. Derive cost estimate 
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Bottom-Up Estimate 



WBS 


Name 


Estimate 


Sum 


Cost 


1 


LAN Installation Project 






34,380 


1.1 


Phase I - Planning and Design 




440 




1.1.1 


A- Kick Off Project 


140 






1.1.2 


B- Build Technical Requirements and 

design 


220 






1.1.3 


C- Review Functional Design 


80 






1.2 


Phase II - Installation Preparation 




26,940 




1.2.1 


A- Order Equipment 


18,240 






1.2.2 


B- Prototype System 


1,200 






1.2.3 


C- Preconfigure system and Test 


3,300 






1.2.4 


D- Prepare Site 


4.200 






1.3 


Phase III - Installation 




5,000 




1.3.1 


A- Install On Site 


3,600 






1.3.2 


B- Establish Documentation Protocols 


200 






1.3.3 


C- Generate Documentation 


1,200 






1.4 


Phase IV - Postinstallation 




2,000 




1.4.1 


A- Conduct Initial Orientation 


1,800 






1.4.2 


B- Review Installation 


100 






1.4.3 


C- Obtain Format Acceptance 


100 







A bottom-up estimate is a very detailed estimate of work to be conducted 
from the work element up, aggregated to reflect total project cost 
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WBS Elements 



The elements of a WBS (in order, by size) are: 

■ Phase 

■ Activity 

■ Task 

Milestones are "markers" indicating the end of one of these 
elements, and the beginning of another 

A work package is the lowest level to which you can assign an 
estimate 
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Definition 



■ Cost estimating: Estimating the costs of the resources needed to 
complete project activities 

■ Cost budgeting: Allocating the cost estimates to individual project 
components so they can be measured or managed 



Validating an Estimate 



Review the definition of the project 

Study ground rules, constraints, and assumptions 

Focus on sources of data 

Compare the estimate with established standards 

Determine whether the methodology is acceptable 

Focus on cost drivers 

Determine whether the estimate meets the objective 
Use a different approach to validate the estimate 
Ensure that all mitigation task are in place 



Basic Concept? ^|pJ§ct'Ma'inagomonl 



©2002 IBM Corpora lion 




The Principles of Estimating 



■ Use the approach most appropriate and the method that is the most 
accurate 

■ Communicate the level of accuracy 

■ Involve the project team in the estimating process 

■ Base estimates on history 

■ Use standards (if available) 

■ Do not back into estimates. (Do not start with a presumed result, then 
work to justify this results.) 

■ Do not pad estimates 

■ Recognize that estimating takes time 

■ Document your assumptions 

■ An estimate is not an estimate if it is not written (assumptions and 
approach), in addition to numerical values 



Key Messages for Module 6 



■ Select the most appropriate approach and the most accurate estimating 
method for your project 

■ Estimating involves resources (human resources, facilities, and material) 
and expenses/costs (direct and indirect) 

■ Estimates should include an indication of accuracy (for example, + - 
percent) 

■ An estimate is not a budget 

a Consider the effort (amount of resources consumed in completed 
deliverables) vs. duration (the number of working days during which the 
task occurs 

■ Validate and finalize the estimate 

» Use the estimate in the project plan 
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Module VI - Team Exercise 
Establishing a Project Estimate 



Based on your WBS, prepare a detailed bottom-up estimate for 
each of your 2 or 3 subproiects . 

Estimate person-hours per task (estimate task effort), then apply 
costs to the hours (estimate task resources $ cost). Determine 
the count of material units and add calculated costs of materials 
used (estimate task material $ cost). 
Include in your estimates the cost of resources and materials, 
estimate for each work package (estimate of resources $ cost, 
estimate of materials $ cost). 

Be sure to estimate the duration for each work package as well 
(computed duration in days). 

Be prepared to present your estimate at a summary level (MS 
Project 2000). 
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Creating a Project Schedule 
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Objectives 
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At the end of this module, you will be able to: 

a Define networks and schedules 

■ Identify types of schedules 

■ Describe specific scheduling considerations, including: 

► Schedule development 
*■ Resource loading 
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Schedules 



A schedule is: 

* The planned dates for performing activities and for meeting milestones 

Use the schedule to: 

■ Determine whether you meet or beat your objectives 

■ Track and communicate your project's progress and status 

■ See how a possible change could affect the project 
» Assign tasks to your staff 
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Types of Project Views 



Tasks 



-13- 
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I — E- 



Precedence 
diagram 



Taskl 
Task 2 
Task 3 



Gantt 
chart 



Tasks: 

1. Design 

2. Build 

3. Test 



Start 



Review 
A 



KEY: 

A Complete 
A in progress 



Approve 

A 

Start 

A 



Review 
A 



Start 
A 



Milestone 
chart 



Complete 
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Network Relationship to the WBS 

WBS 



Network 
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Method for Creating Networks 

Precedence diagramming method (PDM) 

■ A network diagramming technique in which activities are represented by 
boxes (or nodes), each box represents an activity 

■ Activities are linked by precedence relationships 

■ A schematic display of the logical relationship of project activities 
- Drawn from left to right to reflect project chronology 

■ Often incorrectly called a PERT chart 



Start 



Finish 



— --Jt 
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Network Diagram Guidelines 



■ The network diagram starts with a task/work package/activity or 
milestone - 1 or 0 

■ The network diagram ends with a task/work package/activity or 
milestone 

■ There are predecessors for all activities {except the first) 

■ There are successors for all activities (except the last) 

■ The network logic must be updated and current 

■ There are no loops 
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Basic Scheduling Terminology 

■ Activity: A task (work element) performed over a period of time; a 
specific piece of defined work from a WBS 

■ Milestone: Marker, significant event, denotes achievement (time, 
money, task). Milestones can have owners 

■ Milestone: An activity that denotes achievement but has zero time and 
zero dollars associated with it 

■ Milestone: Represents the start or finish of a significant event 

■ Relationships: Dependencies that exist between activities 

■ Lag time: Any delay imposed on the relationship between two activities 

■ Lead time: Modification of a fixed relationship to accelerate the start of a 
successor task 



Precedence Relationships in Precedence Diagramming 
Method (PDM) 1 of 3 

Finish-start (FS) 

■ Pour the concrete; raise the frame 



■ Define requirements; write the code 

■ Set budget; select design 
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Finish-finish (FF) 

■ Want them complete at the same 
time 

■ Examples: 

+ Bake the turkey; bake the yams 

► Reproduce disks; generate 
documentation 

► Select a design; allocate funding 
*- Write code; buy a PC 
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Precedence Relationships in PDM (continued) 3 of 3 

Start-start (SS) 

» Define relationship but not necessary the 
same time 

» Examples: 

► Write text; edit text 

► Install plumbing; install wiring 
*■ Select a design; select vendors 
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Lag Time / Lead Time 

Definition: A change of a relationship that directs a delay in the successor task 

• ► Lag time 




FS + 1 



• Lead time 

i I i I I I U 1 Ill 

Time units 
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Validating Schedule Assumptions 
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Generating the Schedule 

Before finalizing the schedule, examine: 
Roles 

• Is there a complete set of roles for each task ? 

-Action: Add roles where needed 

Staff 

• Who will fill these roles ? 

- Action: Assign staff 

Skills 

• Do the staff assigned possess the needed skills ? 

-Action: Add or change people or re-estimate the duration to allow time to improve 
skill levels 

Availability 

• When will the people really be available ? 

-Action: Reschedule around nonavailable time 

-Action: Change utilization assumptions to adjust duration 

-Action: Add more staff 



Basic Concepts of Project* Management 



©20G2 IBM Corporation 



Add 



Project and Technical Management Tasks 



• Usually level-of-effort tasks 

• Include but are not limited to: 

- Change control management 

- Risk management 
-Communications management 

♦ Status 

♦ Interfaces with other organizations 

♦ Client/Project sponsor 

- Progress management 
-Contract management 

- Project management 

• Include more than just the project manager's time ! 




Scheduling Terminology 



• Early start (ES): Earliest possible time at which an activity can start 

• Late start (LS): Latest possible time at which an activity might begin without 
delaying the project finish date 

• Early finish (EF): Earliest possible time at which an activity can finish 

• Late finish (LF: Latest possible time at which an activity can be completed without 
delaying the project finish date 

• Free float: The amount of time an activity can be delayed without delaying the early 
start of any immediately following activities 

• Total float: The amount of time that an activity may be delayed from its early start 
without delaying the project finish date 

• Critical path: Longest path through the network. It is also the shortest possible time 
to complete the project 



Applying PDM Theory 

















Name 






- WBS Number 






- Duration 
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Forward Pass 



1 of 2 



• Established: Project start date 

• Project start date is the early start date for first network activity 

• Work from left to right, top to bottom of the network 

• When an activity has multiples predecessors (P), select highest early 
finish date as early start date of successor (S) 

• Calculations: 

- ES + Duration = EF 

- EF + Lag = ESS (successor) 



Forward Pass Example 



2 of 2 



Full precedence diagram 

ES EF 



ES 



EF ES 



EF 










jration = 3 


y r*' ■ 


TaskG| 




EF ES 



H 

Duration = 




! 


Task DpIMt 



LS 



EF ES 



LF 



EF 



LS 
ES 



LF 
EF 



I BwNH I 



ES 



EF 







Duration = 2 




Task H BS1 



LS 



LS 



TaskF 



LS 
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Backward Pass 
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• Established: Project finish date (from last activity in forward pass) 

• Project finish date is the late finish date for last network activity in the 
backward pass 

• Work right to left, top to bottom of network 

• When a predecessor (P) has multiple successors (S), select the lowest 
late start date as the late finish of the predecessor 

• Calculations: 

- LF - Duration = LS 

— LS - Lag = LFp (predecessor) 



n 



Backward Pass Example 

Full precedence diagram 

ES ef es 



2 of 2 



EF ES 



EF 



Duration = 7 ^ D 



1 



Task Al 



LS 





1kfl 




Juration = 


6 


Task C 




LS 




LF 


ES 




EF 



| -as 


fill 


Duration = 3 


I 


TaskG|^| 



LF 




ES 



EF 



m 

Duration = 2 I— I 
Task h|~ 



LS 



i m 

^[Juration =^^^ 



TaskF 



LS 
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Float / Slack 



Float = Late finish - Early finish 
Float = Late start - Early start 

- Float > 0 (time is available) 

- Float = 0 (situation is critical) 

- Float < 0 (project is behind / critically late) 







1 



Float is sometimes known as slack 
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Float Example 




Du ration = 3 ^ 



LS 



LF 



LS 







m 




Task F 





Critical Path 



IStartP - 




ES 




EF 






Duration = 
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Task C 




LS 


ft 


LF 


ES 




EF 



EF 





mi 


Duration = 3 


IS 


TaskG lll 




LF 



EF 



Duration = 3 



Hm Task 



LS , 



LF 
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Duration = 2 




Task 



LS 0 LF 



• Longest of all paths through the project 

• Path with zero float/slack time 

• Shortest time to complete the project 
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Steps in Computing a Precedence Network Schedule 



1 . Identify all tasks from the WBS 

2. Establish predecessor and successor relationships, assuming resource 
independence 

3. Complete the process unit all predecessors and successors have been 
identified 

4. Assign resources to tasks to generate duration 

5. Calculate the forward pass; when multiple dates must be passed 
forward, select the latest date 

6. Find the early finish date of the project 

7. Calculate the backward pass; when multiple dates must be passed 
forward, select the earliest date 

8. Calculate float ^ *t C'/ a 

9. Identify the critical path and jiear-critical pa th 

1 0. Validate the network to ensure that it is correct and complete 

1 1 . Become familiar with the characteristics of the network 

12. Adjust schedule, if possible, to meet commitment 
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Network Analysis 



Ensure that your network is complete and current 

► Have you correctly identified your critical path ? 

► Should any task with large^mounts of float be rescheduled ? 

► Are there any d anglers ? jfc v *lp f,< pv&tJ* ?J 

Become familiar with your network and analyze it 

► What risks are on the critical path ? 

► Is there a near-criticai path ? 

► How much float is available ? 

► What types of float exist on which tasks ? 

Ensure that your objectives can be met 

► Do you need to add any milestones ? 

► Which tasks involve external deliverables ? 

► Can the work be completed in the desired time frame ? 

► Will deliveries be made on time ? 
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Adjusting the Schedule to Meet Objectives 
Ways to meet schedule objectives 

■ Change the relationships among tasks so that the critical path is shorter 
(fast-tracking) 

*■ Do tasks in parallel, not in sequence 

► Change approach to work to create a different set of interrelated 
tasks with a shorter critical path (Note: This may change the WBS) 
Change a finish-start relationship to a finish-finish relationship 

■ Change a date constraint so that a task on the critical path can start or 
end sooner 

■ Crash the network (1) to decrease the total project duration after 
analyzing alternatives to see how to get the maximum duration 
compression for the least cost 

(1): Crash the network- Decrease total project duration after analyzing 
alternatives to determine how to get the maximum duration compression for the 
least cost 
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Initial Schedule Is Complete 
But Is It Reality ? 
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Key Messages for Module 7 



■ A schedule is built from the tasks on the WBS 

■ A schedule is built using logical relationships between tasks 

■ A schedule will lead to identifying the critical path 

" Network analysis is important to developing a realistic schedule 

■ Schedules are dynamic and need to be actively managed 

■ Include project and technical management tasks in the schedule 

■ Validate your schedule assumptions and analyze and adjust your 
schedule as need 
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Module VII - Team Exercise 
Calculating the Critical Path 



■ Calculate the critical path by yourself, then share it with your 
team and discuss it 

■ Calculate the forward and backward passes 

■ Calculate the float for each path 

■ Each team will present one critical path calculation 
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Module VII - Team Exercise 
Calculating the Critical Path 
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Objectives 



At the end of this module, you should be able to: 

► List the required baselines for managing a project 

► Describe change management 

► Discuss why change management is important in project 
management 

► Describe what should be included in the change management 
process 

Identify types of changes 

► Describe the typical follow-up actions to change requests 

► List the elements of a change request form 

► Discuss the project manager's role in change management 
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Baselines 



A Baseline is established: 

- Before execution 

- After each approved change 
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Required Baselines for Managing a Project 



Requirements 
Specifications 



i 




Schedule 



Cost 



Without baselines, Scope = oo 
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What is Change Management ? 



The procedures that manage and control the baseline(s) 
A change control system: 

> Includes formal documented procedures to define how to manage 
change 

*- Establishes paperwork, tracking systems, and approval levels 
necessary to authorize change 
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Why Manage Change ? 

Change management: 



■ Is the single most important problem facing the project management 
team 

■ Affect cost, schedule and specifications 

■ Could result in contract changes and amendments 

■ Can originate from anywhere 

With baselines and no change control, scope will become infinity 
(S=co) 
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Change Management Procedure Must Include; 



Change control process 
Change request form 

Change control authority (Change Control Board in the U.S.) 

► Receive 

► Review 

► Recommend 
Change control log 

► Accept 

► Reject 

► Defer 
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Change Management Process 

Change management is an iterative process 





Change Management Process 




■ Specs/requirements 

■ Cost 

■ Schedule 
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Elements of a Change Request Form 



■ Change request number 

■ Date of the change request 

■ Name of the person requesting the change 

■ Description of a change 

■ Estimate of the price of investigation 

■ Statement of the change's effect on the project 

■ List of tasks and staff affected by the change 

■ Estimate of the price of the change 

■ Signature of the authorized representatives 

■ Time limitation on implementing the change request 

■ Time limitation on investigation 

■ Authorization to proceed 

► Investigation 

► Implementation 

■ Effect on related projects 
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Change Request Form 



Date Raised | Raised by 


Number 


Summary 





Detailed Description 



investigation 



Cost of Investigation: $ 



Approval: Yes 



Evaluation 



Date Required 



Priority 



Total Cost 


Comment 


Sub-Project 


Cost 


Comments 















Implementation 



Decision: Accept / Reject / Defer 



Signed 



Incorporate Into Plan By 



Implemented By 



Expiration Date 



Basic Concepts of Project M a riagemo n t 

■ -w35 -r.' - 



5 JQQ2 IBM CocuoratiujK 



Types of Changes 



Changes comes in two ways - both require the same attention 



Technical Changes 



- Implementation of solution 



Usually internal 
Usually in scope 



Contractual Changes 




Terms and Conditions 

Scope of work 

Requirements 

Schedule 

Costs 

Usually external 
Usually out of scope 



A formal change management process must be established and use, and 
include written change orders on ALL projects, both small and large 



Who Can Authorize Change ? 

■ Only authorized representatives accept, reject, defer or negotiate 
changes 

■ Authorized representatives must be designated in writing 
a Change requests must be in writing 
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Typical Follow-Up Actions for Change Requests 



Status Change 
Request 


Within the Scope of the Contract 


Out of the Scope of the Contract 


Accept 


• Plan incorporation into system 
creating new baselines 

• Establish schedule and 
resources 


• Prepare proposal, including price 
to client/project sponsor 

• Do not implement until 
contractual agreement is reach 

• Revise contract 


Reject 


• Communicate and document the 
decision * 


• Communicate and document the 
decision * 


Defer 


• Direct team to perform further 
analysis and/or consider 
alternatives and /or hold until a 
specified time 


• Direct team to perform further 
analysis and/or consider 
alternatives and/or hold until a 
specified time 



* It is important that the originator of the change understand the rejection rationale 




The Project Manager's Role in Change Management 

■ Analyze change requests 

► Assess the effects of the change: risk, baseline 

■ Manage the scope 

> Accept or reject change 

■ Revise baselines 
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Guidelines for Managing Change 



■ Change control should be introduced early in the project 

■ Determine how changes are to be introduced and processed as part of 
the project plan 

• Use a change request to document any proposed changes 

■ Ensure that changes are approved in writing by the authorized 
representatives 

■ Update the baselines and ail appropriate documentation after the 
change is approved 
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Key Messages for Module 8 



■ Changes will occur and cannot be ignored 

■ Changes originate from two sources: 

► Stakeholders 

*■ Project team members 

■ Changes may be: 

*- In scope (no additional cost to client/project sponsor) 
* Out of scope {usually additional cost to client/project sponsor) 
» Change affects the triple constraints (Schedule / Cost / Requirement) 

■ The project team must work with the same baselines to meet project 
objectives 

■ Thus, a formal change process is required 



Change management is your friend 
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Module VIII Team Exercise: 
Handling a Change Request 
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Module VIII - Team Exercise 
Handling a Change Request 



You just received Change Request # 97 in a memo from Perry 
Fields. The customer is requesting a change. How are you 
going to handle it? Document each of the steps you would take. 
Hint: The first step is logging the change in the Change Log. 
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Change Request Form 



Date Raised 






| Raised by 




Number 


Summary 




Detailed Description 


Investigation 


Cost of Investigation 


$ 












Approval: Yes 




No 


Evaluation 


Date Required 


Priority 


Evaluation Summary 


Total Cost 


Comment 


Sub-Project 


Cost 


Comments 














Implementation 


Decision: Accept / Reject / Defer 




Signed 






Incorporate Into Plan By 


Implemented By 








Expiration Date 
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Objectives 



At the end of this module, you should be able to: 

■ Distinguish between project management and project control 

■ Describe the framework for project management 

■ Describe the components of project control 

■ Describe the purpose of project control 

■ Explain the use of earned value 

■ Calculate the earned value 

■ Interpret status measurements 

• Recognize when a project is out of control 



Project Management 



"The project manager is expected to integrate all aspects of the project, 
ensure that the proper knowledge and resources are available when and 
where needed, and above all, ensure that the expected results are 
produced in a timely, cost effective manner" - Meredith and Mantel, 1995, 
p. 4 
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Project Control 



"Control is the process of monitoring, evaluating, and comparing planned 
results with actual results to determine the status of the project's cost, 
schedule, and technical performance objectives" - David I. Cleland, 1994, 
p. 285 
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Why Is Controlling the Project Important ? 

Without control: 

■ Scope = oo (scope creep) 

■ Costs skyrocket 

■ Risks increased 

■ Schedules are missed 
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Four Stages of Control 



■ Establish standard 

■ Observe performance 

■ Compare actual and planned performance 
* Take corrective action 



ofect Management 
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Use of a Project Control Book 



A project control book is a collection of generated documents, which 
may contain multiple volumes 



Use: 



■ As a basis for reviews and audits 

■ As an information repository for team members 

■ As a tool for other project managers (on or off the project) 



BiS sfe Concepts ot Project Management 



- .^KS*" 



©2002 ISM Cofporailorr 



Defining the Project Control Book 



Project Management Plan: Project Control book: 

Plans / Procedures Results / Output 

■ Project tracking and evaluation 

■ Financial management 

■ Reporting 

■ Risk management 

■* Supplier management 

■ Quality management 

■ Change management 

* Issue and problem management 
» Contract management 

■ Organization and people management 

■ Deliverables management 
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PCB Plans/Results Examples 



Project Management Plan: 
Plans / Procedures 



Project Control Book: 
Results /Output 
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Relationship Management is Part of Project Control 




Guidelines for Monitoring a Project Plan 



■ Focus analysis on one cycle of time back and three cycles forward 

► Example: one week back, three weeks forward 
« Identify work completed 

*- Support people doing a good job 

■ Evaluate work that is late starting or completing 

► What is the effect on schedule and budget ? 

► What actions can you identify to mitigate these impacts ? 

► Who should be responsible for any actions ? 

■ Evaluate work that will be starting 

► Ensure that owners know and agree that their work can start on time 
* Apply risk analysis techniques 

■ Evaluate work due to completion 

*- Check with owners to ensure that work is on target 

► Evaluate trends and other data that supports the owners' opinions 

■ Provide update estimates for task completion 

■ Conduct project reviews 

■ Communicate status regularly 

■ Track issue and problem resolution 
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Issue Management 



Problem - A cause for concern that is in the PM's domain of control. 
PM has the enablers to fix this problem. 

Issue - A problem that is affecting PM's area of control; PM does not 
have all the enablers within his/her domain of control to fix it. PM 
must derive an issue to the area of control that can resolve the 
problem. 

■ Manage issues by documenting, assigning responsible parties, and 
tracking them through resolution. An issue management form should 
be filled out with: 

- Issue number 

- Responsible party 

- Issue identification date 

- Date needed by 

- Resolution date 

- Description of resolution 
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Metrics Allow Project Manager to Monitor and 
Communicate Project Status 

What is a metric ? 

■ It is planned 

■ It spans the life of the project 

■ It is trackable 

■ It measures variance 

■ It is understood by the client / project sponsor 
The project manager must : 



Choose metrics appropriate to the specific project 
Determine the preferred metrics of the client / project sponsor 
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Examples of Metrics 



■ Resource utilization and productivity 

B Number of risk events passed or completed 
» Number of changes over time 

■ Earned value 

■ Tasks starts / finishes (planned vs. actual) 

■ Milestones achieved 



What other metrics can be used ? 



Bosic Concepts of Project Management 



■£>2G02 IBM Corporation 




Why Consider an Earned Value Method ? 



Because it : 

■ Allows for objective assessment of variance 

■ Is used and will be used more widely at IBM 

■ Allows for common understanding of the amount of work that actually 
has been done on the project 

■ Is incorporated in all the major modem project management software 
packages 

■ Is consistent for ail project managers 
» Allows for point-in-time analysis 

» Allows for forecast of future performance 

» Can be done at the work element, summary, or project level 



Earned Value Terminology 



What is the planned cost ? 

- Planned Value (PV) or Budgeted cost of work scheduled (BCWS) 
How much has been accomplished against plan ? How much will you 
claim for the work performed and verified ? 

- Earned Value (EV) or Budgeted cost of work performed (BCWP) 
How much has been spent against plan ? 

- Actual Cost (AC) or Actual cost of work performed (ACWP) 
How much will it take to finish ? 

- Estimate to complete (ETC) 
What will it cost when it is done ? 

- Estimate at completion (EAC) 
What is the baseline cost of the project ? 

- Budget at completion (BAC) 
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Earned Value Basics 




Earned Value Example 

PC Installation 



» You need to install 20 PCs in one week 

■ Your labor costs are $800 per day, so your budget at completion is $4000 

■ The hardware is not part of your cost 

■ Your schedule says that you will install 4 PCs per day 

■ Allocating costs against your WBS, one PC installation should cost $200 

At the end of day 2, you have labor costs of $1 600. You must pay labor costs, so 
your actual cost (AC) is $1600. However, you expected to have installed 8 PCs, 
but one of the workers is slow, so you have only installed 6 PCs. The planned 
value (PV) or budgeted cost of work schedule (BCWS) is $ 1600, but the work 
actually accomplished, the earned value (EV) or budgeted cost of work performed 
(BCWP)is$1200. 

You decide you must become current on work performed, so you ask your team 
to work overtime on day 3. They do, adding 1/2 day's cost, or $400, to the actuals 
for day 3. Now your PV is $2400, and so is your EV, so you are back on schedule, 
but your AC is $2800 and you have a cost overrun of $400, with only 2 days left to 
do anything about it. 
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Earned Value Example 



■ Status by day (cumulative): 

> AC is tracked (actual costs) 

► EV is computed (based on work performed) 



Day 


Total PCs 
Plan 


Total PCs 
Inst. 


PV 


AC 


EV 


0 


0 


0 


0 


0 


0 


1 


4 


4 


800 


800 


800 


2 


8 


6 


1600 


1600 


1200 


3 


12 


12 


2400 


2800 


2400 



Current Status Measurements 



Schedule variance (SV) 

■ What's the difference between the value of what we really accomplished 
and what was schedule to be done ? 

SV = EV - PV 

Cost variance (CV) 

■ What's the difference between the value of what we really accomplished 
and what we spent to do it ? 

CV = EV-AC 



Percent complete {% complete) 

■ Real value of work accomplished 
% complete = EV / BAC 

Percent spent (% spent) 

■ Percentage of actual cost spent 
% spent = AC / BAC 
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Earned Value Forecasting 



SPI = 



_ EV 



PV 



CPU 



EV 



AC 



Schedule 
performance index 



EAC = 



BAC 
CPI 



Cost 

performance index 



ETC = EAC - AC 



Estimate 
at completion 



Estimate 
to complete 



Example: Progress Tracking (Part 1) 



At the end of day 2, 

Schedule Performance Index: 

SPI = EV / VP = 1 200 / 1 600 = 0,75 

Cost Performance Index: 

CPU EV/ AC = 1200/1600 = 0,75 

Schedule Variance (SV): 

SV = EV - PV = 1200 - 1 600 = -400 

Cost Variance (CV): 

CV = EV - AC = 1200 - 2400 = -400 
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Example: Progress Tracking (Part 2) 



At the end of day 3, 

Schedule Performance Index: 

SPI = EV / PV = 2400 / 2400 = 1 ,0 

Cost Performance Index: 

CPI = EV / AC = 2400 / 2800 = 0,86 

Schedule Variance (SV): 

SV = EV - PV = 2400 - 2400 = 0 

Cost Variance (CV): 

CV = EV - AC = 2400 - 2800 = -400 
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Example: Progress Tracking (Part 3) 



At the end of day 3, 

To Complete Performance Index 

TCPI = (BAC - EV) / (BAC - AC) = 
= (4000 - 2400) / (4000 - 2800) = 
= 1600/1200 = 1,3 
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Key Messages for Module 9 



Keep the overall project in mind as you look for points of trouble 

Include monitoring of risk, change and issues in activities 

Manage relationships with all stakeholders 

Choose appropriate metric to communicate with stakeholders 

Use baselines to measure and control project progress 

Use earned value as a strategy and a technique to identify project 

problems 
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Module IX Team Exercise: 






Calculating Earned Value 
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Module IX - Team Exercise 
Calculating Earned Value 



Instructions 



Complete the 
Acme Supernova 
Project Assignment 
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Module IX - Team Exercise 
Calculating Earned Value 



Instructions 



It is now 09 April, 1995. You have just received the latest earned value 
data from the Supernova project office. The office is expecting you to 
interpret this mass of data. Your job is to develop a status report using 
earned value, issues, risks, changes, action items, and recovery plans. 

To impress your boss you plan to calculate: 

CV 
SV 

Percentage spent 
Percentage complete 
EAC 
ETC 

...your boss expects a complete report in 30 minutes 
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Objectives 



At the end of this module, you should be able to discuss the 
following: 



■ Independent reviews 

■ Troubled projects 
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Independent Reviews 



■ Independent reviews are opportunities to have experts outside of the 
project team walk through (go over each and every detail) of the 
results of project activities. 

- Provide high quality proposal documents 

o Solution is technically feasible and will fulfill customer 
requirements 

• Estimates and schedules are complete and reasonable 

• Risks are identified, assessed and containment plans in place 

- Provide an objective assessment of the health of the project 
(status, issues, risks) 

• Highlight project accomplishments 
» Identify project- related problems 

« Provide general project management guidance 

- Provide feedback to improve the business (i.e. lessons learned) 



■ Should be execute: 

- On a regular basis 

- Whenever the project manager changes 





1 Bl^ConcopU Dl Project Manager,., C2002 IBM Cw'poSiS^ ... " . 




■ 




U 


S> „ «. ^..JP&4* "-Jit- r" *CW*«* , :i ,,,!J!.U.U!'.-. "im** 



In Reviews, The Key Question Is "Where Are You ? 



You must answer the following questions: 

■ Where should the project be ? 

■ How much has been done ? 

■ How much has it cost ? 

■ How much will it take to finish ? 

« What will it cost when it is done ? 



In Reviews, The Key Question is "Where Are You ? 



You must answer the following questions: 

» Where should the project be ? Planned Value 
a How much has been done ? Earned Value 

■ How much has it cost ? Actual Cost 

■ How much will it take to finish ? Estimate to Complete 

■ What will it cost when it is done ? Estimate at Completion 
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Independent Reviews Tasks 



a Review project documentation - especially the Project Control Book 
(PCB) 

■ Review cost data 

■ Review schedule data 

■ Review risk management plan 
» Review change control log 

■ Review results of previous Quality Assurance reviview(s) 

■ Assess contract health 

■ Interview selected team members and the client / project sponsor 

■ Analyze the information collected 

■ Prepare a report of findings and recommendations 



Independent reviews are NOT audits 



Reviews in IPD 




Concept 



Plan 


Develop 


Qualify 


Launch 


Life Cycle 








m 


m m 













Decision Checkpoints (DCPs) are structured project reviews with specific entry and exit 
criteria used to measure progress of a project. 
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WW Quality Assurance Process (Solution Design) 

Solution Design 



Opportunity 
validated/ 
Qualification 





PraposaTf 
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Proposal Baseline Assessment 
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Engagement f 

OA Pr oceanic • performed by Subject Matter Experts 

QA Procedure - performed by accredited QA 
representative 



Contract Baseline 
Review 
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WW Quality Assurance Process (Solution Delivery) 

Solution Delivery 




Design 



INITIAL 





.. Project, 
Management 
i Review * ' : 






ON-GOING 



Project 
Management 
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QA Procedure - performed by accredited QA 
representative 
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QA during Opportunity Qualification: 



Pre-bid Consulting 

Utilizes Quality Assurance industry / competency skills and experiences along 
with available intellectual capital, e.g. lessons learned analyses, to 

• assist the opportunity team in driving a winning strategy 

• reduce, contain, and mitigate risks early in the engagement process 

• enable a streamlined and tailored Quality Assurance process approach 

Answers the Key Questions: How can we win and is it worth winning? 
Business Benefit: A strengthened win strategy 




QA during Solution Design: 



Technical and Delivery Assessment 

Provides a review of the technical aspects of the solution to ensure that 
the proposed solution will fulfill customer requirements, is technically viable 
and can be delivered by IBM 

• the estimates and schedules are complete and reasonable 

• the technical risks are identified, assessed and containment plans are in 
place 

There are three components to this assessment: 

• technical Assurance for the various components 

• a review of the overall solution 

• commitment by the delivery organ ization(s) to perform the work 

Answers the Key Questions: Can we deliver the proposed solution? 
Business Benefit: Mitigation of two primary root causes of a troubled 
project: inaccurate estimates and infeasible solutions 
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QA during Solution Design: 



Proposal Baseline Assessment 

Teaming of Quality Assurance and the engagement team to reduce, contain 
and mitigate risk. The work effort is continuous while designing the solution 
and it is scalable based upon the complexity of the proposal. It provides an 
assessment of the overall solution and the documented proposal to validate 
that: 

• the solution is designed to satisfy both IBM's and the customer's 
objectives 

• the estimates, schedules, and cost case are complete and reasonable 

• delivery responsibilities are clearly defined among all parties involved 

• the technical, business, and project risks are identified, assessed, and 
containment plans are in place 

Answers the Key Questions: Should we propose the solution? 
Business Benefit: Scalability allows for speed-to-market 
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QA during Solution Design: 



Contract Baseline Review 

Provides a review and risk assessment of the changes made during 
negotiations and after the Proposal Baseline Assessment. The Contract 
Baseline Review is required primarily for larger and more complex 
opportunities that have had changes made during negotiations. 



Answers the Key Questions: How well can we deliver the solution? 
Business Benefit: Provides additional information to management and 
the delivery team about risk and the recommended actions to assist the 
project team during delivery 
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QA during Solution Delivery: 



Project Management Review 

Provides an independent and objective assessment of the status of the 
project, issues, financial position, and risks. Frequency of reviews are based 
upon complexity and project "health". Verification is made to see if the project 

is: 

• being managed in accordance with the contractual commitment and 
project plan 

• meeting planned profitability 

• satisfying the customer's requirements and expectations 



Answers the Key Questions: How well are we doing against the contract, 
plans, and customer expectations? 

Business Benefit: Assist the project team In delivering a successful 
solution and increasing customer loyalty 



Trouble Projects 

■ A project is considered "Trouble Project" when: 

The project has significant problems that require the application of corrective plans. 
- For example - The probability exists of exceeding the estimates and / or the 
budgets or the client's is very dissatisfied and there is financial exposure to lost 
Revenue unless direct managerial action is taken to put to the project back under 
control 

► Bigger problems exist with a definitive serious financial exposure, political exposure, loss 
of support for an IBM Program solution or product, subcontractor exposure, and / or 
significant clients' dissatisfaction (many time provided to IBM in Writing). 

> The project has financial problems where 25% or more contingency on the project has 
been used , or the contract is experiencing a 10% or more less GP than was planned for 
the project. The project can be on schedule but have this issue and will be considered 
"Troubled Financially" and will be put under this process to try and address the financial 
issues. 

* Project that has received a "C" or "D" classification during a PMR = Trouble Project 
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Troubled Projects, Root Causes, White Paper 



The "White Paper" 

The White Paper is a Global Services Document, yet the lessons are 
universal. 

■ The paper is based on findings of Project Management Reviews and 
on analysis of Troubled Projects 



Given all that is known about troubled projects, why do projects still 
fail ? 
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Why the projects fail ? 



48% of QA PMR findings on troubled contracts in delivery are issues that originated 
during the marketing/engagement cycle. The clearly predominant finding is 
"Expectation Mismatch", i.e., customer expectations that are different from those 
being delivered under the IBM contract. Usually, these are expectations set during 
the proposal phase, sometimes verbally (versus what was in either the proposal or the 
contract). The next most prevalent finding are "Inaccurate Estimates" (project cost 
estimating done during Solution Design / Proposal Development), and "Unclear 
Requirements", i.e., the customer's true requirements were not fully addressed by the 
IBM scope of work contracted. 

52% of QA PMR findings are issues related the way we are delivering the solution. 
The overwhelmingly prevalent finding related to contract delivery is lack of 
fundamental project management discipline, including no project planning/tracking, no 
change control, no risk management and poor project organization. 
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Trouble Projects Root Causes 



4.0% 



2.7% 



!1 .3% 




1 3.3% 



10.7% 



12.4% 



1 3.3% 





Estimate 




Risk 




Scope 


■ 


Contract 




Client 


m 


Technical 




Quality 




Tracking 




Subcontractor 




Resource 


s 


Finances 




Com m unlc. 



Analisis of root causes based on a trouble project sample. 



Root Causes categories 



■ Root Causes categories 



► Solution Design 

- Customer Expectations 

- Planning / Estimating 

- Requirements Issues 

- SOW / DoMussues 

- QA Violations 
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Solution Delivery 

- Project Management 

- Resource Issues 

- Customer Issues 

- Subcontractor Issues 

- Internal IBM Issues 

- No signed Contract 





Root Causes from Solution Design 



■ Customer Expectations 

Failure to set and manage customer expectations 
*■ Multiple contracts / work orders perceived as one 



■ Planning / Estimating 

► Fixed-price contracts for combined phases 
Concessions during negotiations with no price increase 

*- Failure to adhere to published pricing guidelines 

- Inaccurate project estimates 

* Failure to plan for risk containment 

*■ Lack of transition plan from marketing to delivery 

► Inaccurate staffing plans 
*■ Insufficient test plans 

► Failure to properly use an approved IBM methodology (i.e., GS Method, 

► WWPMM, etc.) 

► Failure to properly use intellectual capital from previous engagement(s) 
>■ Customer transaction volumes lower than estimated 



Root Causes from Solution Design (cont.) 



■ Requirements Issues 

► Failure to reach common understanding of requirements or completion 

► criteria 

>- Failure to reach understanding of the proposed solution 

*- Failure to establish appropriate contractual baseline 



- SOW/ DO U Issues 

► Poorly constructed or unauthorized subcontractor SOWs 
*- Penalty clauses in SOW 
*■ Poor quality Proposals and / or SOWs 
Lack of DOU with other IBM organization (s) 



■ QA Violations 

>■ Failure to perform QA reviews during Solution Design 
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Root Causes from Solution Delivery 



■ Project Management 

► Ineffective project startup 

► Unclear / ineffective project organization 

► Lack of or inadequate project management discipline 

► Failure to perform QA reviews during Solution Delivery 

► Lack of management oversight / support 

► Failure to implement / exercise proper change management process 

► Starting a phase prior to completing a preceding phase 

► Continuous / constant change in scope 

► Lack of engagement hand-off plan / meeting (SO) 

► Ineffective / insufficient financial management 

► Ineffective communications 

► Ineffective staffing plans 
*■ Insufficient testing 



Root Causes from Solution Delivery (cont.) 



Project Management fconU 

► Poor customer satisfaction 

► Lack of or inadequate project management plan / schedule 

► Inadequate follow-up on action plans from prior review(s) 

*■ Not properly using approved IBM methodology {i.e., GS Method, 
WWPMM, 

► etc.) 

*■ Lack of or inadequate risk management plan 

Lack of or inadequate plan to submit and / or reuse intellectual 
capital 

Resource Issues 

► Inability to acquire properly skilled resources 

*■ Unplanned turnover of key project team members. 
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Root Causes from Solution Delivery (cont) 



Customer Issues 

► Unfulfilled customer responsibilities 

► Customer unprepared to support the new system 
*■ Customer represented by Third Party 

► Change in customer management team 

► Ineffective relationship between IBM and customer 
* Customer having financial problems 



Subcontractor Issues 

*■ Unfulfilled subcontractor responsibilities 

► Ineffective relationship between IBM and subcontractor 

► Subcontractor cost overruns 



Root Causes from Solution Delivery (cont.) 



■ Internal IBM Issues 

► Problems with OEM or IBM products 

► Technology / architecture issues 

► Failure of IBM to fulfill responsibilities with customer or other IBM 
*■ organization(s) 

► IBM project team morale or organizational issues 
* Ineffective relationship between IBM organizations 

► IBM / Third Party alliance issues 

► Multisite development issues 
*> Offshore development issues 



■ No Signed Contract 

* Working without a signed contract or PCA 
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Seven Keys to Success 



■ Project health assesment method developed by PriceWaterhouse 
Cooper (PWC) 

■ Adopted by WWPMM and IBM worldwide 

■ Keep sponsors focused on the major issues 

*■ it's a "universal yardstick" to measure projects 
*>• Use as an executive mgt communication technique 

- Helps establish a consisten agenda far meetings 

- Helps prioritize issues 

- Anticipates problems 

- Sets action plans in advance 



Applying the Seven Keys 
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Key Messages for Module 10 

In this module, you did the following: 

■ Discussed independent reviews 

■ Discussed the Troubled Projects White Paper and applied project 
management principles in formulating solutions to issue 
management, change control, and inadequate project management 
issues. 

■ Apply the seven keys assesment to the Olympics Case Study 
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Introduction 

Troubled projects have a significant impact on ISM'S profitability as well as a far 
reaching negative impact on IBM's reputation for high customer satisfaction and quality 
service. There are several things that can be done to prevent a troubled project, but 
one of the best ways to avoid a troubled project early on is for proposal and project 
teams to understand and follow IBM's Worldwide Quality Assurance Process. Available 
documentation supporting the implementation of the WW OA Process as well as links to 
other relevant databases can be obtained from the WW Quality Assurance database 
which can be accessed from the IBM intranet: http://w3.ibm.com/servicgs/n a 
Quality Assurance staffs are available to help proposal and project teams understand 
the process as well as help identify risks and develop effective containment strategies. 

Another way for IBM teams to avoid troubled projects is to understand the root causes 
that can trigger one and apply the suggested prevention measures when a root cause is 
identified during the lifecycle of the opportunity. The root causes identified in this 
document are based on a closed-loop QA lessons learned process that analyzes 
Project Management Reviews from troubled projects. As a result of this analysis, many 
lessons have been learned about the most common problems and trends (hat result in a 
troubled project. Coupled with each root cause are a set of prevention measures that 
have been compiled by the Woridwide Quality Assurance Knowledge Management 
team from their experience and expertise. The prevention measures should be 
considered as a means to reduce or contain the root causes - and thereby to improve 
project quality, profitability and customer satisfaction. This list is not intended to be a 
complete list of problem areas - nor an exhaustive offering of prevention measures. 
Experience and professional judgment should be applied to unique circumstances when 
determining the appropriate "measures of prevention" for any particular proposal or 
project. 

To better understand the flow of this document it is important to understand the QA 
lessons learned process. Project Management Review (PMR) reports are reviewed and 
analyzed, resulting in a list of the root causes that led to the problems in the project. 
This list of root causes is then consolidated with the root causes from all troubled 
projects to look for trends and to rank the root causes by frequency of occurrence. 

The fact that the lessons learned / root cause analysis is performed on PMR reports 
implies that the project is in delivery when the root causes are identified - and that is 
true. It does not, however, mean that all root causes occur in delivery. In fact, quite the 
contrary. Many of the root causes identified during the delivery phase are actually the 
result of actions taken (or not taken) during the design phase. For that reason, the root 
causes are divided into two major sections: "Root Causes from Solution Design" and 
"Root Causes from Solution Delivery." Several / many of the root causes under these 
two categories may sound like the same root cause - and in fact many of them are. The 
difference is, however, that the root cause in design means that proper action or 
Prevention Measures to Avoid Troubled Projects Pagei 



planning was not applied when the proposal or contract was being written, while the 
same root cause in delivery means that it was covered property in the design phase but 
was not executed properly after the contract was signed and the project went into 
delivery. To illustrate this, consider root cause #1208-lnsufficient test plans and 
#51 13-lnsufficient testing. They may appear to be identical. But #1208 Is from the 
design phase, meaning that we didn't plan for sufficient time and resources to perform 
testing during the project. #51 13 on the other hand, Is from the delivery phase, 
meaning that we didn't actually perform sufficient testing while working on the project. 
In some situations both root causes may apply - we didn't plan for and didn't execute 
sufficient testing. In other cases the design side only may apply - we didnt plan for 
sufficient testing, but we actually performed sufficient testing during delivery (as the 
result of a PCR or adjustments to the hours by the Project Manager). On other projects, 
however, the delivery side only may apply - we planned for sufficient testing but just 
didn't do it. 

Beneath the two major sections of Design and Delivery, the individual root causes are 
grouped Into six categories, as follows: 

Root Causes from Solution Design 

Customer Expectations 

Planning / Estimating 

Requirements Issues 

SOW/DOU Issues 

OA violations 

Multinational Issues 

Root Causes from Solution Delivery 
Project Management 
Resource Issues 
Customer Issues 
Subcontractor Issues 
Internal I8M Issues 
No Signed Contract 

The root causes are each numbered, but the numbering schema has no relationship to 
the frequency of occurrence. The numbers are merely a four-digit number, with the first 
digit identifying the phase (1=Design / 5=Delivery), the second digit identifying the group 
within a phase, and the third / fourth digits simply being a sequential number within the 
group. 

For each root cause, a brief description is included along with suggested prevention 
measures for each. 

The results of the lessons learned / root cause analysis work are available in a couple of 
different presentations. The first, entitled "Lessons Learned / Root Cause Analyses", 
works very well in a 45-minute conference call or "lunch & learn" type of setting. The 
second, entitled "Why Services Projects Fail" can also be given during a conference 
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call. In addition, it is being con verted to a webcast format for online viewing. If you 
would like more information or to include one of these presentations during a team call 
or lunch & learn , contact aahelp/Southburv/IBM&IBMUS . 

Finally, additional prevention measures for the root causes are always welcome and 
appreciated. Submit them in a Lotus Note to gahelp/Southburv/lBUmiBMUS . 
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Root Causes from Solution Design 



1101. Failure to set and manage customer expectations 

Description: 

Many problems in services projects stem from IBM's failure to meet customer 
expectations. IBM has substantial control over setting the appropriate customer 
expectations if the solution is correctly marketed and effective communications 
are established. Presentations or verbal comments made during the marketing 
phase/sales cycle, while seemingly innocent, may be perceived by a customer as 
a commitment by IBM and set a false expectation or may be used by the 
customer to leverage concessions from IBM when disputes arise over scope or 
responsibilities. 



Prevention Measures: 

• Be careful when setting customer expectations. Be conservative in 
describing a project and try to "under promise and over deliver" rather than 
"over promise and under deliver." 

• Caution the customer about the challenges of the project. 

• Make sure the customer fully understands and agrees with IBM's proposed 
solution. 

• Include experienced services delivery resources early in the discussions with 
the customer regarding the potential solution. 

• Do not underestimate the complexity, cost, and time required to develop and 
implement the solution. 

• Encourage the customer to budget for changes upfront so the customer will 
have the flexibility to address their changing requirements during the project 
without seeking additional internal funding. 

• Inform the customer of "bad news" as early as possible. Consutt with 
experienced IBM personnel to develop a strategy to "package* the news 
effectively. 

• Communicate with all appropriate levels within the customer organization. 

• At the beginning of a project, document with the customer (heir expectations 
and priorities. Once the expectations and priorities are established, the 
project team should list actions which will be taken to meet those 
expectations. 

• When appropriate, get the customer to acknowledge the risks and, if possible, 
agree to the contingency plan. 

• Make sure the customer fully understands the Importance of their involvement 
and responsibilities in the project. The customer's full involvement and 
commitment are essential to the sucoess of a project. The customer should 
think of themselves as part of a team rather than spectators. The 
IBM/customer team will either succeed together or fall together. 
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• Conduct a formal hand-off between marketing and delivery. This should be 
planned during the Contract Baseline Review. 

• The PM or PE should review the scope with the customer before 
implementation and Include the customer in scope planning to identify 
discrepancies early (i.e., have the customer assist with the work breakdown 
structure). 

• Conduct fully facilitated Joint Application Requirement (JAR) and Joint 
Application Development (JAD) sessions, obtaining customer agreement and 
signoff at the completion of each activity. 



1 102. Multiple contracts / work orders perceived as one 

Description: 

IBM often has multiple contracts / projects open with a single customer at a given 
time. Unfortunately the customer doesn't always see these as distinct and 
separate contracts but perceives them as one big contract. Consequently, if one 
project becomes troubled and has problems - the customer perceives that all 
projects are troubled. 

Prevention Measures: 

• Set customer expectations early in the implementation phase. 

• During initial meetings with the customer at contract startup time it should be 
made clear that the effort is standalone and does not have any connection to 
other efforts currently being implemented by IBM. 

• Clearly identify and classify all IBM contracts and existing work orders 
associated with the respective customer account. Determine which contracts 
or work orders, if any, will or coutd have a direct impact on your project or 
contract and classify these as Dependencies. These should be a part of a 
Dependency management plan. Clearly communicate and document these 
differences to the customer. 

• The Project Executive should report on each contract separately during the 
monthly meeting and other occasions. Each contract should have an 
identifiable, unique name. 

• Create individual contract billing. 

• If multiple contracts are needed, and dependencies exist, then C&N should 
be involved in negotiations early and the PM should be well aware of how to 
manage the dependencies. 

■ If "multiple* PMs exist, then a DOU between them should be agreed upon and 
a communication plan must be established. 
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Planning / Estimating 



1201. Fixed-price contracts for combined phases 

Description: 

A fixed-price contract for a multiphase project may be a profitable way to 
structure a deal when IBM has a significant amount of successful experience with 
thedevelopment/implementationofaparticularsoiutionoroffering. H oweve r, 
in cases where we do not have sufficient experience, the project may be 
underestimated in terms of both cost and schedule. This is especially true when 
the fixed price covers future phases for which trie requirements are not fully 
understood or documented, or when the input for a future phase Is dependent on 
the deliverables from a prior phase. Unless the scope of an engagement is 
defined in detail with very accurate estimates (by an experienced project team), 
the chances that a fixed-price multiphase project will complete on-time and within 
budget are slim. Factors which make fixed-price contracts undesirable include: 

• lack of project team relevant experience; 

• untested components in new environment; 

• lack of detailed specifications to guide development; 

• unanticipated technical glitches; 

• multiphase projects which include requirements, design and 
implementation; 

• built-in conflict of interests (i.e. desire for provider to limit efforts and 
customer to expand scope under a fixed-price contract); and 

• not fully understanding the customer's requirements. 

Prevention Measures: 

• Limit fixed-price engagements to: 

- short, relatively simple projects or phases, or 

- projects that have been done successfully before by the project team. 

• Large projects should be broken into logical phases with each phase bid 
separately. 

• For large projects with no detailed design specifications, IBM should bid only 
the requirements validation and solution design phases (preferably time and 
materials). 

• Marketing efforts should be focused on level-of-effort contracts where the 
customer pays for the work they receive. 

« If the customer requires an estimate for the entire project, a budget & 
planning or indicative price should be presented to the customer. These are 
non-binding estimates used for planning and budgeting purposes. 

• Structure the deal to put limits on the level of effort that will be devoted to 
certain specified tasks. If more effort is required, change control Is used to 
obtain more customer funding. (NOTE: This requires tracking and reporting 
to the customer the hours used on the specified level of effort tasks.) 

« If fixed price is a customer requirement or the only option, consider a pilot 
phase at a fixed price that will enable better estimates to be made for the full 
scope. 
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• The SOW should have an assumption which states that IBM will validate the 
estimates at the completion of each phase and use the PCR process to 
document changes in scope, price, and schedule. If we have bound our 
original estimate with enough specificity, we should be in a position to 
effectively implement change control. 

• During the engagement phase, it becomes very obvious whether the initial 
requirements provided by Ihe customer are detailed enough to make a 
reasonable estimate. In most cases, additional clarification is required. If 
this is the case, a two Phase approach should be presented to the customer, 
Phase 1 for refining and further clarifying the requirements and bounding the 
overall scope, Phase 2 for the implementation based on the resultant output 
of Phase 1. 



1202. Concessions during negotiations with no price Increase 

Description: 

Acceptance of additional terms and conditions or increasing scope and/or 
responsibilities during contract negotiations without increasing the price often 
causes a project to be unprofitable or less profitable than projected. 

Prevention Measures: 

• Involve IBM management, Contracts & Negotiations, Legal, Quality 
Assurance, and/or Pricing in the negotiation strategy sessions as needed. 

• Make it dear that IBM wants the business and is willing to negotiate a 
reduced scope in order to reduce the price, but also make it clear that IBM will 
not accept terms that make the deal unprofitable. 

« In the event that work must begin before the contract is finalized, ensure that 
all appropriate levels of IBM management are in agreement with the decision, 
that it is a calculated decision, and that an appropriate Letter of Authorization 
has been signed. It is important to understand that IBM loses a great deal of 
negotiating leverage when it begins a project before the contract has been 
signed. 

• The PE/PM responsible for the delivery of the proposed solution must be a 
key participant and have final approval/disapproval of the proposed 
concessions. 



1203. Failure to adhere to published pricing guidelines 

Description: 

During the marketing phase, IBM associates often underprice or "low-ball" the 
price in order to "get our foot in the customer's door." The plan in these cases is 
to make up the profit on a future phase or project. As a result of underpricing, 
projects are under financial pressure from the beginning and even minor 
overruns cannot be easily accommodated. Do not expect customer flexibility or 
sympathy in cases where IBM has underpriced a project. Customers often do 
not care or appreciate the fact that IBM is losing money on a particular project. 
They often believe IBM will make it up in some other way or on some other 
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account. Additionally, customers are generally unwilling to accept higher prices 
on later phases or projects once they have been given a lower price. 

Prevention Measures: 

« Follow authorized pricing methodology and guidelines. 
■ Obtain approval of authorized pricer. This is required when the estimated 
gross profit falls below the minimum allowed gross profit. 

• Obtain formal Quality Assurance approval of the proposal via the Proposal 
Baseline Assessment. 

• Do not reduce estimates simply to lower price. Reduce actual scope to 
reduce price. 

• Document the business case to support any pricing guideline deviations. 

• Obtain approvals from line management and Pricing for any pricing 
deviations. 



1204. Inaccurate project estimates 

Description: 

Many projects have been financially doomed from the beginning as a result of 
underestimating the effort required to complete a project. Although Quality 
Assurance helps provide a certain level of validation, utilizing independent 
technical resources to validate the estimates is key to reducing the risk of 
underestimating the project effort. 

Prevention Measures: 

• Utilize experienced project team members to develop or validate the 
estimates either during proposal preparation or at contract start. 

• Technical & Delivery Assessments, in addition to Proposal Baseline 
Assessments and Contract Baseline Reviews, should be conducted to 
validate estimates and schedules. Experienced staff should review estimates 
during technical reviews. 

• Use the most appropriate estimating tools available. 

• Make adjustments for 

- the learning curve of new development tools and methodologies, 

- systems management efforts, 

- untested hardware and software components, 

- subcontractor underestimates, 

- adequate testing and correction periods, and 

- unknown risks. 

• Review Intellectual Capital for similar completed contracts for actual costs. 

• Include Subject Matter Experts and Project Managers for a bottom-up, or task 
level, estimate of hours. 

• Price to win, but not to a price point. Ensure that the appropriate skills have 
been identified and are available for the engagement. Too often our staffing 
and associated pricing is done to meet a perceived customer price point by 
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manipulating "Band Levels" and ignoring the skills required to implement the 
solution. 

• Use viable historical data whenever possible when estimating projects where 
we have previously implemented a similar solution. 

1205. Failure to plan for risk containment 

Description: 

All projects involve some risks. The risks should be understood and planned for 
prior to beginning a project Both technical and business risks should be 
addressed. Many risks can be avoided or reduced once they have been 
identified. By effectively mitigating the identified risks during the design phase, 
the overall contingency and thus price to (he customer can be reduced. 

Prevention Measures: 

• Use GS Risk (the Global Services Risk Assessment tool) to help identify risk 
areas and develop containment actions and strategies. GS Risk can be 
downloaded from the PM Tool Suite Web Site at 

• Utilize Quality Assurance reviews to identify risks and develop containment 
actions and strategies. 

• Create a Risk Management Plan during the proposal preparation stage. 
Develop a Risk Management Plan to eliminate, reduce or contain the risks. 
Review the plan with Quality Assurance and management to ensure that it 
covers the major risks and has appropriate plans to contain them. 

• Maintain/update the Risk Management Plan throughout the life of the project. 

• Conduct a Contract Baseline Review to ensure that the risks identified during 
proposal development have been addressed by the project team and actions 
are being taken to address those risks. 

1206. Lack of transition plan from marketing to delivery 

Description: 

Unless a sound transition from the proposal team to the perform team takes 
place, much information may be lost or misunderstood with regard to the project 
background and customer expectations. 

Prevention Measures: 

• Ensure that project delivery personnel are involved during the marketing 
process and that marketing personnel are accountable and responsible for 
proper transition to the delivery team. 

« For large or complex projects, conduct the initial Project Management 
Review, as required per the WW OA Process. 

• Upon contract award, schedule a formal transition meeting between the 
marketing team and the delivery team. The agenda should include: 

- Customer organization & personalities 

- Customer expectations 
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- Alignment of expectations with thB SOW 

- Review verbal commitments 



1207. Inaccurate staffing plans 

Description: 

During the proposal development phase plans, skills, resources, and number of 
hours for each task are created. In many situations the skills thought necessary 
on a project do not actually match the skills required to deliver me project. For 
example, the staffing plan calls for DB2 programmers when in realfty it was C++ 
programmers that were needed. This would also include a poor estimate of 
when specific skills are required to join and/or leave the project team. In other 
words, we may have correctly estimated the correct skill needed and we may 
have correctly estimated the number of hours needed, but we planned to have 
them on the project during the month of January and we really needed them 
during the month of April. 

Prevention Measures: 

• Use Subject Matter Experts and Project Managers to validate estimates and 
scope. 

• The responsible PE/PM for delivery of the solution must be involved and 
signoff on the staffing plans. 

1208. Insufficient test plans 

Description: 

For many projects, time for testing is required. All too often, the time allocated 
for testing Is insufficient and/or doesn't allow for time to do follow-on testing when 
the first set of testing points out problems that must be addressed. 

Prevention Measures: 

• Include a Pilot or Testing Phase in the SOW and include provision for 
subsequent Pilot/Test period as appropriate. 

• Include resource hours for the Pilot/Test phase in the pricing. 

■ Include the Pitot/T est phase in the project plan and share with the customer 
such that schedule expectations are set. 

• Re-baseline the schedule with the customer and IBM team. 

• Have the necessary subject matter experts (SMEs) conduct a technical 
review of the Test Plan to ensure that enough time has been allocated to 
effectively test and regression test the solution. 

• The use of GSMethod or other such methodologies should aid in defining the 
appropriate Test Plans. 

• Check the IC AssetWeb for Test Plans from similar projects that can be used 
as the baseline for the development of your project specific plan. 

• A test manager or test expert should be involved during the engagement 
phase to validate the viability of the proposed testing plans and schedules. 
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During Delivery a test manager / expert must be assigned as a member of the 
project team. This testing resource must be factored into the cost case. 

1209. Failure to properly use an approved IBM methodology (I.e., GS Method, 
WWPMM, etc.) 

Description: 

IBM has developed methodologies that are intended to help improve quality, 
reduce cost, and ultimately improve profitability. These methodologies include 
intellectual capital, work products, and templates designed to reduce the amount 
of time necessary for project team members to deliver a project. When these 
methodologies are not used we are beginning with a blank piece of paper which 
results in higher costs and inconsistent project delivery. 

Prevention Measures: 

• Provide continued education of the project management community on the 
merits of WWPMM and other applicable methodologies 

• Identify lack of a methodology during Initial Project and Plan PMR. 

• Ensure that key members of the project team have the appropriate 
experience, skills and knowledge to effectively implement and execute the 
approved IBM methodologies such as WWPMM and GS Method. Ensure 
that these resources are factored into the staffing plans and cost case during 
the engagement delivery phase. 

• The Project Manager should select an approved methodology prior to the 
start of the project. This is an essential part of developing the project plan. 

• Recommend that a method expert or similar SME work with the team and 
review the proposal. 

1210. Failure to property use intellectual capital from previous engagements) 

Description: 

IBM has captured a lot of good intellectual capital from projects that have been 
delivered successfully. This intellectual capital can be very useful in helping a 
proposal team properly estimate and develop a new Work Breakdown Structure 
as well as to identify any potential deliverables Uiat might be reused. As a result 
the estimate will be more reliable and the profitability can be increased. 

Prevention Measures: 

• Ensure that the proposal team has searched the ICM Assetweb for 
intellectual capital from a similar project. 

1211. Customer transaction volumes lower than estimated 

Description: 

This root cause occurs most typically in ITS projects where the project financial 
are transaction or incident-based, but could occur on projects in other LOBs if 
priced on a transaction or incident basis. In these cases the project financial 
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are calculated based on an estimated number of transactions occurring (i.e., 
installing X workstations, upgrading software on X computers, etc.). By signing 
the contract, trie customer commits to the estimated number of transactions and 
IBM's planned profitability is calculated on the entire number of estimated 
transactions occurring. When the customer fails to meet their committed number 
of transactions, IBM is unable to Invoice the customer, and consequently the 
profitability of the project is impacted. 

Prevention Measures: 

• Ensure that each instance of the Transaction" is priced at an agreed to profit 
margin. 

• Use a Tier" method of pricing. The more transactions the lower the price. 

■ Do not apportion project management and project administrative time across 
estimated volumes. Make provision in me SOW for a minimum price for 
project management and project administration regardless of volume. 

• Include minimum quantities in the SOW with penalties if minimum quantities 
are not realized. 

■ Include a maximum number of incidents/orders that can occur within a 
monthly time frame. This will encourage fewer incidents/orders with larger 
volumes. 

• Contracts should have a 'baseline evaluation " clause to validate the 
customer's baseline and adjust the price if the contracted level is not met. 
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Requirements Issues 

1301. Failure to reach common understanding of requirements or completion 
criteria 

Description: 

It is not uncommon for IBM's interpretation of the requirements for a project to 
differ from the customer's interpretation. Requirements are even interpreted 
differently by different people within the customer's organization. Because of the 
potential for varying interpretations of requirements and the impact to costs and 
customer satisfaction as a result of misinterpretations, it is very important that 
IBM have a clear and common understanding of the customer's requirements. If 
the contract has already been signed, resolving the misunderstanding often 
becomes extremely contentious when additional costs or schedule delays are 
involved. Disagreements as to requirements may often result in customer 
dissatisfaction. To address customer satisfaction, IBM may be required to deliver 
a more expensive solution as a result of the misinterpretation of requirements. 

Prevention Measures: 

• Ensure that appropriately skilled and experienced personnel are involved in 
the marketing phase and proposal development. 

• To avoid misunderstandings between IBM and the customer regarding the 
requirements, IBM should arrange to have a "walk-through" of the 
requirements. 

• The first phase of the contract could be designed as a requirements validation 
and solution design phase. 

• IBM should try to persuade the customer to allow IBM to validate the 
requirements and proposed solution with the users even if the RFP process 
does not specify a validation step. 

• During the marketing discussions and in the IBM cover letter and proposal, 
state that IBM recommends a joint walk-through of the requirements, the 
Statement of Work and solution description before the contract is signed. 

• include the customer in scope planning sessions to assist with developing the 
Work Breakdown Structure. Doing so will help in identification of any 
mismatch in customer expectations. 

• Requirements should not just be reviewed by the customer, they should be 
"approved" through a formal process before the project moves forward. Ifs 
better to address misunderstandings in the eariy stages of the project before 
the design and development activities begin. 

• Conduct fully facilitated Joint Application Requirements and Joint Application 
Development sessions at the beginning of the project to establish the project 
baseline and refine the scope of work. The objective is to have the customer 
signoff on the requirements and design at the completion of these activities, 
upon which time they are frozen and any changes are subject to change 
control. 

1302. Failure to reach understanding of the proposed solution 
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Description: 

There have been situations where IBM clearly understood the customer's 
technical requirements, but IBM's solution was not how the customer wanted its 
requirements met. There are often many different approaches and technical 
solutions (often with significantly different costs) which meet particular 
requirements. Some solutions are acceptable to a customer and some are 
unacceptable to the customer, even though (hey technically meet the 
requirements. To avoid costly disputes, the customer should have a clear 
understanding of IBM's proposed solution and how it meets their requirements. 
If the contract has already been signed, resolving a misunderstanding often 
becomes extremely contentious if additional costs or schedule delays are 
involved. 



Prevention Measures: 

(These are the same prevention measures as #1 301 , except the focus is on the 
solution details rather than the requirements.) 

• Ensure that appropriately skilled and experienced personnel are involved in 
the marketing phase and proposal development. 

• To avoid misunderstandings between IBM and the customer regarding IBM's 
proposed solution, IBM should arrange to have a "walk-through" of the 
proposed solution. 

• The first phase of the contract could be designed as a requirements validation 
and solution design phase. 

• IBM should try to persuade the customer to allow IBM to validate the 
requirements and proposed solution with the users even if the RFP process 
does not specify a validation step. 

• During the marketing discussions and in the IBM cover letter and proposal, 
state that IBM recommends a joint walk-through of the requirements, the 
Statement of Work and solution description before the contract is signed. 

• Conduct fully facilitated Joint Application Requirements (JAR) and Joint 
Application Development (JAD) sessions at the beginning of the project to 
establish the project baseline and refine the scope of work. The objective is 
to have the customer signoff on the requirements and design at the 
completion of these activities, upon which time they are frozen and any 
changes are subject to change control. 



1303. Failure to establish appropriate contractual baseline 

Description: 

For Systems Integration and Application Development (SI/AD) projects, 
requirements documents generally serve as a poor contractual baseline. A 
customer's documented requirements can be addressed with a variety of 
solutions which involve a variety of costs to deliver. Managing change and scope 
can be extremely difficult when the customer's requirements serve as the 
baseline. If the requirements serve as the technical baseline, and IBM discovers 
that it must develop a different solution than It originally priced, IBM has no basis 
to go back for a change order if the requirements have not changed. If IBM's 
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proposed solution serves as the technical baseline and it is decided that a 
different solution should be implemented, IBM can then issue a change order to 
cover any additional costs incurred as a result of the new approach. Note, 
however, that if IBM has failed to describe in detail the solution that was 
proposed and priced, then IBM has a very weak position to establish whether a 
different approach is a change to the baseline. Requirements documents for 
Strategic Outsourcing projects work well as a baseline because IBM wants the 
option of finding more efficient approaches to meet the customer's processing 
requirements. To the extent IBM can meet the requirements by using less costly 
approaches and technology, IBM usually profits. 

Prevention Measures: 

• For SI/AD projects, avoid using customer requirements documents as the 
sole contractual baseline. Use IBM's proposed solution description in the 
SOW or proposal as the baseline upon which change orders will be 
established. 

• Customer requirements documents can be used for Strategic Outsourcing 
projects without the same risks as SHAD projects. 

• IBM's proposal for SI/AD projects should include a detailed solution 
description (not just tasks descriptions) which should serve as (he baseline 
until the external design is developed. 

• IBM's solution description can be included in the proposal, SOW or 
referenced as an appendix to the SOW. 

• Unless the contract is on a lime and materials basis to develop a solution 
based on a customer requirements document, IBM should, to the extent 
practical, be vary careful in using a requirements document as a contractual 
baseline for a solution. 

• One alternative to using (he requirements as a baseline is for IBM's proposal 
to include a detailed solution description (not just task descriptions) which 
could serve as the baseline until the external design is developed. The 
solution description should also cross-reference the requirements so the 
customer can understand how IBM's proposed solution addresses each 
requirement. IBM's solution description can be included in the proposal, 
SOW or referenced as an appendix to the SOW. Once the external design is 
developed, it (along with any approved change orders) should supersede the 
solution description as the baseline. 

• For RAD development, the scope should be bounded in additional ways such 
as maximum number of iterations or up to X amount of hours per function. 

• If IBM cannot describe the solution in detail at the inception of the contract, a 
Time and Materials Design Phase should be proposed. When the Design 
Phase is complete, IBM can then bid on the implementation phase with a 
clear understanding of the effort required 

• Include all relevant assumptions in the SOW. 

• Conduct fully facilitated Joint Application Requirements (JAR) and Joint 
Application Development (JAD) sessions at the beginning of the project to 
establish the project baseline and refine the scope of work. The objective is 
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to have the customer signoff on the requirements and design at the 
completion of these activities, upon which time they are frozen and any 
changes are subject to change control. 
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SOW / DOU Issues 

1401. Poorly constructed or unauthorized subcontractor SOWs 
Description: 

IBM has been left with little leverage when a subcontractor has been selected 
and committed to the customer before IBM has established an appropriate SOW 
and contract with the subcontractor. Experienced subcontractors have in some 
instances "out-negotiated" I8M marketing and delivery personnel who attempted 
to structure deals without the assistance of experienced IBM contract personnel. 
As a result, IBM ends up absorbing more costs than were originally intended. 

Prevention Measures: 

• Follow standard IBM procurement process. 

• Ensure IBM procurement and/or contract staffs are involved prior to 
contacting subcontractor for discussions. Utilize the experience and guidance 
of the IBM procurement and/or Contracts & Negotiations staffs. 

• Contact an IBM Resource Manager to ensure no IBM resources are available 
to provide the services sought from a subcontractor. 

• Determine if the subcontractor is qualified and if they have an existing IBM 
Subcontractor Agreement in place 

• Make sure the subcontractor thinks you are considering other subcontractors 
{even if you are not seriously considering others) so the contractor will give 
you a competitive bid. 

• Make sure the subcontractor SOW is mapped to the Customer SOW 
obligations and assumptions. 

1402. Penalty clauses In SOW 

Description: 

In some situations a customer may request (or insist) that penalty clauses be 
included in an SOW. This is especially true if the customer's protect is 
time-sensitive and they have concerns that IBM may not be able to complete the 
project within the required timeframe. Penalty clauses might also be requested 
by the customer as protection for IBM not meeting any service level agreements 
(SLAs) that are included in the SOW. These penalty clauses, if exercised, may 
negativery impact the profitability of the contract. Including penatty clauses 
doesn't cause the problem, but not understanding or managing them is a 
problem. 

Prevention Measures: 

« Avoid using penatty clauses unless absolutely necessary. 
« If used, be certain that Legal and/or Contracts & Negotialions have approved 
them. 

• Ensure that the conditions for when a penalty clause can be exercised are 
clearly defined. 
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If penalty clauses are requested, try to negotiate bonus clauses for early 
completion or above average performance. 



1403. Poor quality Proposals and / or SOWs 

Description: 

One of the main reasons for poor quality proposals is the lack at time allocated to 
properly, write them. Proper proposal preparation is essential to providing a high 
quality proposal that addresses the customer's needs and protects IBM's 
interests. Poor quality proposals and SOWs also result from failure to utilize the 
Quality Assurance reviews to check the quality and content of the bids. In a 
number of troubled projects, it was discovered that the project team failed to 
follow the recommendations of the Quality Assurance Reviews. Independent 
Quality Assurance reviews are of little value if the review recommendations are 
disregarded. The consequences of a poorly defined or constructed SOW are 
that the Project Manager has no solid basis to create a project plan and disputes 
over scope are difficult to reconcile. 

Prevention Measures: 

• Decline to bid on a project if there is inadequate time to prepare a quality 
proposal. It is better to decline to bid, than to submit an embarrassing or 
unprofitable proposal. 

- Attend the Services Proposal Development Workshop (N229J), available 
through ISM Global Campus. 

• Conduct a proposal development meeting for the proposal team. 

• Consider the development of the proposal as a mini-project. Assign a 
proposal team leader to manage the proposal development project. 

• First create a Work Breakdown Structure (WBS) for the project and then 
develop the proposal based on the WBS. 

• Involve Competency Leaders/specialists in developing the solution. 

• Use peer reviews to obtain independent opinion of clarity and completeness. 

• Request independent technical reviews to validate the feasibility and ensure 
that nothing is overlooked or misrepresented. 

• Obtain formal Quality Assurance approval per the WW OA Process. Make 
sure that Quality Assurance has the time to review the final proposal 
documents that will go to the customer. 

• Review proposed SOWs internally with management, Quality Assurance, 
Finance and Legal as appropriate before they are presented to the customer. 
Quality Assurance and experienced staff can Identify and suggest removal or 
rewording of parts of a proposal which may have a negative impact to IBM. 
Once a customer sees something that is beneficial to them In a proposal, it is 
very difficult to change or ramnvs it 

■ Make sure all proposals and SOWs clearly state what is in scope and what is 

out and include the required SOW components. 
« Make sure the Customer SOW is mapped to the Subcontractor SOW 

obligations and assumptions. 
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1404. Lack of DOU with other IBM organizations) 
Description: 

It is often necessary to use resources from more than one IBM organization 
during the delivery of a project. When this occurs, one resource is the contract 
owner and the other organ iza lion (s) act in the role of a service provider to the 
contract owner - almost in a subcontract type of role It is important to have a 
Document ot Understanding (DOU) between the contract owning organization 
and each of the service provider organizations to ensure that everyone 
understands the tasks to be performed, the timeframe that the work is to be 
performed, how recoveries and expenses will be handled, etc. The DOU 
becomes the "contract" between IBM organizations in much the same way that a 
Subcontractor SOW is the contract between IBM and an external subcontractor. 
Not having a DOU almost always leads to misunderstandings, disagreements, 
and a breakdown in the internal IBM relationship (see also #5505: Ineffective 
relationship between IBM organizations). 

Prevention Measures: 

• Ensure that a DOU is written and agreed to by both parties prior to the start of 
a contract. 

• If the tasks to be performed are dependent upon the service provider 
organization, the DOU should be agreed to before submitting a proposal to 
the customer. 
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OA Violations 

1501. Failure to perform OA reviews during Solution Design 

Description: 

When projects are bid without adequate Quality Assurance reviews, IBM has 
failed to comply with its own Worldwide Quality Assurance Process. Many 
potential problems and quality issues are identified through the Quality 
Assurance Proposal Baseline Assessment. Failure to follow Quality Assurance 
recommendations is also a common source of project problems. 

Prevention Measures: 

• Follow the WW OA Process. All proposals should have: 

- a Technical & Delivery Assessment 

- a Proposal Baseline Assessment, and 

- a Contract Baseline Review. 

• Quality Assurance staffs are available to help explain the proper steps and 
procedures which must be followed. 

• Ensure that all action items identified by Quality Assurance reviews have 
been closed to the satisfaction of Quality Assurance. If a recommendation is 
not followed, the reason for noncompliance should be documented and 
forwarded to line management and Quality Assurance Management. 

• The proposal team should briBf its line management on the proposed project 
and risks identified through the Proposal Baseline Assessment. Informed 
management concurrence should be obtained to proceed. 
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Multinational Issues 

1601. Failure to properly handle multinational issues 

Description: 

Many of IBM's large customers are becoming more global. As a result we often 
find our projects spanning many countries and geographies. There are several 
ways in which multinational contracts can be written, but in all cases the IBM 
offices in the countries where work is to be performed must be involved in the 
development and approval of the proposal. There are many legal, human 
resource, tax, and other issues that must be considered - and the local country is 
best suited for addressing these issues. 



Prevention Measures: 

• Involve Contracts & Negotiations, Finance/Pricing, and/or Legal early in the 
proposal development cycle. 

■ Identify each country where work is to be performed and the individuals in 
those countries that can provide assistance in the development of the 
proposal. 

• Ensure that the DOU with the lead country has been agreed to and signed by 
all participating countries prior to the start of a contract. 
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Pro] act Management 

5101. Ineffective project startup 

Description: 

Failure of the IBM Project Manager and Customer Project Manager to review the 
SOW as the appropriate definition of the scope. The customer should also be 
aware of the project plan and how the customer personnel will be used as a part 
of the overall project. See also #51 02: Unclear / ineffective project organization. 

Prevention Measures: 

• At the commencement of every project, ensure that the IBM Project Manager 
(reviews the SOW with the Customer Project Manager and obtains full 
concurrence regarding the tasks, IBM and Customer Responsibilities, 
deliverables, completion criteria, change control procedures, schedule, 
project organization and roles, etc. 

• If any disagreements occur, ensure that marketing personnel and line 
management are involved to remedy the disagreement. Ensure that any 
resulting changes to the SOW are formally incorporated via the change 
control procedure before the project proceeds. 

• Hold a customer kickoff meeting to Introduce the customer and IBM team 
members and stakeholders to each other and to define roles and 
responsibilities. Use the kickoff meeting to: 

- Define scope (not develop work breakdown) 

- Identify the purpose of the project and expected output 

- Identify potential risks and preliminary plans (hold additional risk 

management sessions throughout the project) 

- Present immediate plans for the project and describe what each project 

team member will be doing in the next several days. 

• Include the customer in the project planning session(s) to assist with defining 
the Work Breakdown Structure. Make the project planning session different 
than the project kickoff meeting. 

• Ensure Contract Initiation Services (CIS) is engaged early in the contract or 
before signing (if imminent). CIS provides the startup expertise required to 
ensure an effective project start. 

• Conduct the initial Project Management Review per the WW OA Process. 



5102. Unclear/ Ineffective project organization 

Description: 

Projects often begin with confusion as to who does what because the roles and 
responsibilities are not well defined. 

Prevention Measures: 
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• At the commencement of every project, ensure that the IBM Project Manager 
reviews the SOW with the Customer Project Manager and obtains full 
concurrence regarding the tasks, IBM and Customer Responsibilities, 
deliverables, completion criteria, schedule, project organization and roles, etc 

• If any disagreements occur, ensure that marketing personnel and line 
management are involved to remedy the disagreement. Ensure that any 
resulting changes to the SOW are formally incorporated via the change 
management process before the project proceeds. 

• Conduct the initial Project Management Review per the WW OA Process. 

• Define the project organization along with the roles and responsibilities of 
each team member. The customer's staff should also clearly understand their 
responsibilities. 

• Define an escalation process for IBM and the customer as well as ensure 
there is a management communication plan. 

• Establish a joint customer/IBM "steering committee" to facilitate project 
oversight and decisions. 

• Hold a customer kickoff meeting to introduce the customer and IBM team 
members and stakeholders to each other and to define roles and 
responsibilities. Use the kickoff meeting to: 

- Define scope (not develop work breakdown) 

- Identify the purpose of the project and expected output 

- Identify potential risks and preliminary plans (hold additional risk 

management sessions throughout the project) 

- Present immediate plans far the project and describe what each project 

team member will be doing in the next several days. 

• Include the customer in the project planning session(s) to assist with defining 
the Work Breakdown Structure. Make the project planning session different 
than the project kickoff meeting. 

• Ensure Contract Initiation Services (CIS) is engaged early in the contract or 
before signing (if imminent). CIS provides the startup expertise required to 
ensure an effective project start. 

5103. Lack of or Inadequate project management discipline 

Description: 

In a number of cases, poor execution of proper project management techniques 
and processes is the cause of unsuccessful projects. Inexperienced project 
managers and project teams are sometimes assigned a project which they are 
not prepared to manage without assistance. In many instances, a skilled project 
manager is removed from the project cos! case in order to reduce the price to the 
customer. In these situations the project management tasks are generally 
assigned to another team member who is not skilled in proper project 
management practices (i.e., architect, developer, etc.). As a result, projects end 
up being managed inconsistently and, if a change in IBM Project Managers 
occurs, the transition between them becomes more difficult. 

Prevention Measures: 



Prevention Measures to Avoid Troubled Projects 



II)]])) 



I ) I J J ) I 1 



• Follow the IBM Worldwide Project Management Methodology (WWPMM). 

• Properly train all project managers and provide close supervision of projects 
from the beginning. 

• In projects where project managers have limited experience or training, an 
experienced project manager should be assigned to closely review the project 
plans and ongoing project status, 

• For large, complex projects, ensure that a certified project manager has been 
assigned. 

• Do not remove the project management role in order to reduce projects costs. 
Reduce scope if cost needs to be reduced. 

■ When the project is initiated, the project manager should request an early 
Project Management Review to ensure the project is on the right track. 

• Implement effective tracking mechanism and tools to track actuals against 
estimates with revalidation of the estimates to complete activities. 

• Assign a skilled project administrator to assist the project manager - 
especially with the use of project planning and tracking tools. 

• The owning Delivery Executive must provide effective management oversight 
to insure Initially that the project management function is adequately staffed 
with skilled resources and to ensure that the PM methodologies and discipline 
are being used and executed effectively during delivery. 

5104. Failure to perform QA reviews during Solution Delivery 

Description: 

Project Management Reviews (PMRs) are sometimes not scheduled until the 
project is in serious trouble. By that time, it is often too late to avoid significant 
problems. In addition, the Project Manager's failure to follow the advice and 
action items from the Project Management Review often results in the problems 
continuing or becoming worse (see also #5116: Inadequate follow-up on action 
plans from prior reviews). 

Prevention Measures: 

• Ensure timely Project Management Reviews (PMRs) by independent Quality 
Assurance staff are held. A PMR schedule should be developed with Quality 
Assurance at contract execution and adhered to throughout the life of the 
contract. 

■ Ensure follow-through on action plans which result from PMRs. 
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5105. Lack of management oversight / support 

Description: 

Line Management in some cases does not have a good mechanism to track its 
respective portfolio of projects and therefore, projects often become troubled 
before they come to the attention of management. Management assistance is 
sometimes provided too late. 

Prevention Measures: 

• Line management in the geographies and industries should ensure that a 
mechanism is in place to closely track the status of all significant projects. 

• A Project Management Review schedule should be developed and tracked in 
all geographies and industries to identify which projects are not being 
reviewed as required. 

• Close monitoring of troubled projects by line management should be 
instituted. 

■ Project Executives and Project Managers should keep their line executives 
briefed on a frequent basis with regard to the status of ail projects. The 
briefings should Include project actuals vs. plan, risk management issues and 
actions as well as requests for management assistance. 

• Project Executives and Project Managers should keep their line executives 
briefed on a frequent basis with regard to the status of all projects. The 
briefings should include project actuals vs. plan, risk management issues and 
actions as well as requests for management assistance. 

51 OS. Failure to implement / exercise proper change management process 

Descripbon: 

Many well intentioned project teams make changes during a project without the 
formality of change authorizations. Without these change authorizations, it is 
often difficult for IBM to defend our actions, intent or baseline when disputes 
arise over scope or overruns. 'Defeat scope creep* 

Prevention Measures: 

• Ensure the change management process is clearly defined in the SOW. 

« Encourage the customer to fund a bucket of hours dedicated for approved 
changes (and investigative charges). This may be anywhere from 5 to 25% 
of the contract value depending on the length of the conlract and the number 
of expected changes. 

• Stress the importance of adhering to a formal, documented change 
management process. Following such a process is as much in the 
customer's interest as it is to IBM. 

• During project kickoff, walk through Ihe change management process with the 
customer team 

• Early in the project use the change management process to authorize a 
change which has no cost or schedule impact The customer is much more 
agreeable to signing a change authorization if it does not cost them anything. 
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By executing a no-cost change order, you and the customer will have set a 
precedent as to how changes must be approved. 

• Execute the change management process for every change, whether or not 
there is a change in cost or price. Otherwise "no cost changes" may lead to 
overall scope creep that will negatively impact the project at a later time. 

■ Encourage the customer to participate in the change control process through 
the use of the Project Charge Request form. 

• Ensure a Project Change Log is put in effect early to track all changes, 
including those that are rejected. 

• Sequentially number all changes for the sake of clarity. 

5107. Starting a phase prior to completing a preceding phase 

Description: 

Starting a phase before a related preceding phase is complete is a risky decision. 
Much rework may be required as a result of work beginning prematurely. The 
client may refuse to pay for the rework required. It has been proven time and 
time again that this tactic does not work. 

Prevention Measures: 

• Ensure that the Project Manager plans and executes the project in a manner 
that does not allow a phase (or task) to start before a dependent predecessor 
phase has been completed. 

• Ensure that the Services Delivery Unit Management regularly assesses the 
status of the project and is aware (by reading status reports and attending 
status meetings) of any decisions to start a phase before a prior phase has 
been completed. 

« For every Activity or Phase, entry and exit criteria must be documented, 
identifying thB inputs, the outputs, and the validation process for determining 
if the entry / exit criteria have been met. 

5108. Continuous / constant change in scope 

Description: 

Everyone understands that there will nearly always be changes in scope during 
the life of a project. And there are usually change management processes in 
place to address these changes. But in some circumstances the customer 
makes continuous changes to the scope of a project. Sometimes these 
requested changes are large and have a significant impact on the project. This 
usually occurs when the customer doesn't have a clear understanding of what 
they want, or frequently change their mind about what they want. While changes 
can be handled through change management, constant change in scope often 
means rework and frustration for the project team. It can also mean that the 
project manager is so fully occupied with understanding, documenting and 
issuing change authorizations (hat they canl focus on the actual task of 
managing the project. 
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Prevention Measures: 

• Ensure the scope and requirements are dearly identified and understood by 
all parties prior to starting wo rk. 

• Be sure to incorporate the changes into the Work Breakdown Structure and 
keep the customer constantly advised of the impact of the changes on the 
schedule as wetl as the cost. By doing so, the customer will understand the 
impact of the excessive changes on the schedule and price. 

• Schedule impacts, solution quality and stability impacts should be the main 
topics of discussion with the customer PM and Executives when trying to 
address this issue. 

• Ensure the contract change management process is enforced for ali 
requested scope changes. 

• Include the impact / cost on the total project for each change. 

• If changes are too frequent, try to establish a release plan. Create frequent 
releases which supply function to the customer to prevent the original plan 
from continuous extensions without deliverables. 

5109. Lack of engagement hand-off plan / meeting (SO) 

Description: 

All projects should have an engagement handoff plan to facilitate transfer of the 
engagement from sales/marketing (Client Solution Executive) to the account 
management team (Project Executive and Project Office staff). This is 
especially true - and CRITICAL - on big SO opportunities where the marketing 
and negotiations phase can take many, many months. Without an engagement 
handoff plan, the account management team is often unaware of the final terms 
and conditions, responsibilities, tasks, deliverables, etc. of the contract and are 
not prepared to meet the customer's expectations or provide direction to the IBM 
service providers who will actually deliver the services to the customer. 

Prevention Measures: 

• Ensure that an engagement hand-off plan is developed and agreed to by IBM 
sales/marketing and account management. 

• Ensure that the engagement hand-off meeting and formal hand-off occurs 

• Review results of OA Contract Baseline Review. 

• Ensure the IBM service providers are conducting their Technical Transition 
Meeting and beginning to prepare the detailed transition plans required to 
perform technical transition and transformation. Obtain tock-in on Transition 
cost and completion criteria. 

• Ensure IBM HR and Finance are preparing / executing the detailed transition 
plans required to perform the HR and Financial transition. 

• Attempt to involve the Project Executive in the Solution Design phase. 

• Attempt to continue the involvement of the Client Solution Executive in the 
early stages of the Solution Delivery phase. 

• Contract Initiation Services (CIS) should be engaged when the contract 
signing is assured to develop a list of contract deliverables (especially those 
which are due during the first month after signing.) 
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5110. Ineffective / insufficient financial management 

Description: 

One of the many tasks a project manager is responsible for is the financial 
management of the project. This includes reconciling labor hours, travel and 
other expenses, customer billings, etc Failure to properly manage the financials 
often result in lost revenue or expense recoveries because the project manager 
is unable to validate the accuracy of customer invoices. 

Prevention Measures: 

• Validate project financials on a weekly basis and correct errors immediately. 

• Validate labor and expenses billed to the customer to ensure accuracy. 
Correct errors immediately. 

• Review invoices with the customer to ensure they understand and are in 
agreement. 

■ Validate lhat all invoices are being paid on a timely basis so that revenue can 
be realized for the project and an accurate gross profit can be calculated. 

• Create a financial baseline that reflects the cost and price as specified in the 
pricing tool that was used to price the SOW. 

• Update the financial baseline with approved Change Authorizations. 

• Track the costs and the invoices (revenue) against the baseline. 

• System generated invoices may not provide sufficient detail to satisfy the 
customer's Accounts Payable requirements. Therefore, establish the 
customer's requirements for the formal for invoices at the outset of a project. 

« Review the Contract Cross Profit Report, or general ledger report, on a 
monthly basis to verify that costs and revenues have been appropriately 
recorded, and were applied under the cored accounting codes. 

• The project plans and Work Breakdown Structures should be at the level of 
detail to facilitate earned value measurements and tracking. 

5111. Ineffective communications 

Description: 

It is critical that project managers have an effective communications plan with the 
customer, the project team, and IBM management. Troubled projects are often 
the result of simply having no regular status reporting, customer meetings, 
project team meetings, etc. tn these situations the customer is unaware of the 
progress being made on a project. Without regular status reporting , the 
customer is also unaware of issues that may need their involvement and 
attention. The same can be said for IBM management. Without proper and 
effective communications, everyone assumes that the project is on schedule, on 
budget, and progressing as planned. Later, when the project is in trouble, it is 
too late to start trying to document all of the issues that have contributed to the 
project's troubled Status. 

Prevention Measures: 
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• Develop a communications / escalation plan at the beginning of the project. 

• Ensure that regular communications and status reporting occur on a regular 
basis (as defined in the communications plan) with the customer, project 
team, and I8M management throughout the life of the project. 

• Keep the customer advised of the smallest of delays or improvements in the 
schedule on a weekly basis. A delay in the schedule should not be 
undisclosed to the customer on the premise that *it can be made up" without 
the need for me customer to know. 

• Project Governance must be established at the start of the project and 
documented either in a separate document or as part of the PMP. This 
establishes the baseline for the majority of the project communications and 
how the project will be managed on a day to day basis. This also helps 
reduce some learning curve lime as new project members join the team. 

5112. Ineffective staffing plans 

Description: 

It is important that staffing plans be accurate and complete. A well-defined 
staffing plan enables the project manager to know what skills will be needed on a 
project and for how long. Without an effective staffing plan, tne project manager 
is often unable to obtain the right skills at the right time. 

Prevention Measures: 

■ Ensure that a staffing plan is developed prior to the start of a project. 

• Work with the appropriate Resource Deployment Managers (RDMs) or other 
staffing personnel to make them aware of what skills will be needed and 
when. 

• Until a project plan can be created, use the estimates that were used In the 
pricing tool to determine initial resource requirements for the staffing plan. 
Once the project plan is created, use it to validate and update the resource 
plan. The project plan will determine not only the number of resources and 
skills required, but will also indicate when the resources will be required. 

• A project should always be staffed with resources that possess the 
appropriate skills, experience and knowledge to "jump start" Ihe project and 
ensure successful delivery. Ineffective staffing plans are mainly a direct 
result of the engagement team trying to staff the project with less expensive / 
lower band level resources in order to lower the cost. 

■ Ensure a project plan is developed and used throughout the project life. This 
will ensure all tasks are staffed and any deficiencies are made visible at the 
earliest point in time. 



5113. Insufficient testing 

Description: 

Testing is usually included in the project management plan/schedule when 
appropriate. All too often, however, the amount of time is underestimated or is 
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reduced in an effort to cut project costs. Testing for rework is often 
underestimated as well. 

Prevention Measures: 

• Ensure that subject matter experts participate in the development of the 
testing estimates. 

• Ensure that "superstar" estimating doesn't influence the amount of testing 
needed. Superstar estimating occurs when a highly skilled expert with many 
years of experience provides an estimate that canl be achieved by the less 
experienced practitioners that will be performing the work on the project. 

• Assign a Test Manager / Expert to the project. 

51 14. Poor customer satisfaction 

Description: 

In some situations the customer often becomes dissatisfied during the life of a 
project for one reason or another. One might argue that poor customer 
satisfaction is actually the result of other root causes occurring - and that is true. 
But in some situations the customer has become dissatisfied with IBM for some 
other reason and this can result in problems for the project manager and team. 
Ultimately the project manager has to work with his or her management and the 
customer to ensure that the customer is satisfied with the work on their project, 
regardless of the customer's other issues with IBM. 

Prevention Measures: 

• Ensure the customer is advised of the Issues Management Process that 
should have been put in place at the beginning of the project and encouraged 
to use it to document the reasons for their dissatisfaction, tn other words, 
implement the Issues Management Process at the beginning of the project 
and ensure the customer is aware of the process and encouraged to use it. 

• During the implementation of any project, there will be some form of customer 
satisfaction Issue. If the IBM PEs/PMs are doing their jobs effectively and in a 
disciplined fashion, this will be the case, especially In the areas of change 
control / scope management, adhering to the established entry and exit 
criteria, etc. A true measure of customer satisfaction is whether we deliver a 
quality solution on time, within the projected budget, that meets the 
customer's requirements. 

• Customer dissatisfaction is usually the result of a long term problem, issue or 
misunderstanding. These causes cannot be fixed overnight. Consider 
bringing in an outside party, such as Relationship Alignment Solutions, to 
work with the customer and IBM to understand the root causes and develop 
solutions. 

5115. Lack of or inadequate project management plan / schedule 

Description: 
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A current project management plan/schedule is one of the fundamentals of good 
project management. Not having a current schedule results in the project 
manager being unaware of what tasks are due, what work has been completed, 
what work remains to be done, how many hours have been spent on a task, etc. 
Failure to maintain a project management schedule nearly always results in a 
troubled project. 

Prevention Measures: 

• Ensure that a current project management plan/schedule was developed prior 
to the start of the project and that it is kept current throughout the life of the 
project. 

• Ensure that the Project Manager has the skills to create a project plan using a 
project planning tool such as Microsoft Project. 

■ Ensure that the project has assigned an experienced Project Administrator, 
preferably a Jr. PM, to assist the PM in the PM plan development, scheduling 
and tracking. Individuals in this role should have an in-depth knowledge in 
the use of whatever PM tool will be used on the project. 

• A contract which has multiple, related and/or dependent projects and phases 
requires an additional level of planning. An integrated plan for the entire 
group is required to ensure any dependencies are met. Customer and 
subcontractor plans should be included. The integrated plan can be used to 
manage the project. 

51 16. Inadequate follow-up on action plans from prior review(s) 

Description: 

Failure by the Project Manager to follow the advice and action items from the 
Project Management Review often results in the problems continuing or 
becoming worse. 

Prevention Measures: 

• Ensure that an action plan is developed to address the findings and 
recommendations identified during a Project Management Review. 

• Assign each of the action items to the appropriate person for completion and 
identify a due date for each. 

• Monitor the action plan to validate that the action items are being completed. 

• Report the status of the action items, as appropriate, between PMRs and 
prior to the next PMR. 

■ Make the action plan part of the interna! status report to line management and 
executives, and report the status of the action items in each report. 

• The responsible Delivery Exec must provide the management oversight to 
ensure that the action plans are addressed, providing whatever executive 
support to the PM is necessary to complete the identified actions. 

5117. Not properly using approved IBM methodology (i.e., GS Method, WWPMM 
etc.) 
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Description: 

IBM has spent a great deal of time and money developing various methodologies 
for project management (WWPMM and PMP) and for technical delivery (Global 
Services Method}. These methodologies contain valuable information, work 
products, templates, etc. designed to help project teams improve efficiency and 
profitability on a project. Using these methodologies also creates a level of 
consistency between projects so that project team members are able to move 
between projects more easily. Not using one of the approved methodologies 
generally results in a "reinventing the wheel" and "starting from scratch* 
environment. 

Prevention Measures: 

• Ensure that one of the approved IBM project management methodologies 
(WWPMM or PMP) is being used on the project. 

« Ensure that Global Services Method is being used as the technical delivery 
methodology on the project. 

• Ensure that key members of the project team have Ihe appropriate 
experience, skills and knowledge to effectively implement and execute the 
approved I8M methodologies such as WWPMM and GS Method. Ensure 
that these resources are factored into the staffing plans and cost case during 
the engagement delivery phase. 

5118. Lack of or Inadequate risk management plan 

Description: 

A risk management plan, including mitigation actions, should be prepared prior to 
the beginning of the project as part of the proposal development. Once the 
project Is in delivery, the risk management plan should be updated and 
maintained throughout the life of the engagement. This helps project managers 
and management be aware of new risks that arise so that they can be closely 
monitored and managed appropriately. Failure to have a current risk 
management plan can leave IBM unprepared to address issues in a timely 
manner. 

Prevention Measures: 

• Use the GS Risk tool to create a risk management plan during the proposal 
development cycle. 

• Update and maintain the risk management plan throughout the life of the 
project. 

• Include the customer in the risk management sessions where appropriate. 
Customers are usually far more aware of the types and frequencies of risk 
that can affect their line of business. This also helps the customer accept 
their responsibilities as far as risk response. 

5119. Lack of or Inadequate plan to submit and / or reuse intellectual capital 

Description: 
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The inventory of intellectual capital available to project teams to be used on 
projects is one of IBM's greatest assets. This inventory, however, is only 
valuable if it is collected and then reused successfully on future projects. It is 
important that IBM project teams have a plan to submit new intellectual capital to 
the ICM Assetweb as part of their project tasks and that they also have a plan to 
reuse existing intellectual capital in order to reduce development time and cost. 

Prevention Measures: 

• Maintain / update a plan to submit and reuse intellectual capital during the 
delivery of every project. 
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Resource issues 

5201. Inability to acquire properly skilled resources 

Description: 

The IBM Project Manager may spend a considerable amount of unplanned time 
to locate and acquire the resources needed to perform the project. In some 
cases these resources cannot be quickly found or end up costing more than the 
cost case estimated. 

Prevention Measures: 

• Ensure that Documents of Understanding are in place, as applicable, to 
formally commit resources prior to committing a bid to the customer. 

• Particularly for key planned resources, ensure that appropriate management 
(Resource Managers) are aware of and committed to the provider 
responsibilities. 

• Review formal staffing plan with a resource manager and line management to 
ensure that appropriate staffing can be secured. 

5202. Unplanned turnover of key project team members. 

Description: 

As a result of unplanned staff turnover, cost and schedule overruns occur 
because of delays caused by the time required to locate replacements, actually 
make them available to work, and bring them up to speed on the specifics of the 
project. 

Prevention Measures: 

• Ensure that the IBM Project Manager has a "succession plan' in place for key 
project team members In the event that they leave the project for personal or 
business reasons. This plan should include the identification of potential 
replacements with comparable experience/expertise along with the manner in 
which a transition of responsibilities from the original person to the 
replacement might take place. 

• Ensure that the IBM Project Manager practices 'cross-training* so that in the 
event a key project team member leaves the project, an existing peer on the 
project could at least temporarily handle the responsibilities until a permanent 
replacement is brought in. This can help keep disruption minimized. 

• As part of the project Resource Management plan, make sure each team 
member's roles and responsibilities are defined and updated accordingly. 
Doing so will make it easier when communicating the need for a replacement 
from a resource deployment manager. 
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Customer Issues 



5301. Unfulfilled customer responsibilities 

Description: 

In some cases, the customer does not have the resources, skills, infrastructure or 
time to support the implementation of IBM's proposed solution. As a result, the 
project fails behind schedule, IBM may be required to assume customer 
responsibilities and/or the project may not proceed as planned. Do not assume 
that just because the SOW clearly states the Customer Responsibilities, that the 
customer has the skills or resource availability to meet those responsibilities. 

Prevention Measures: 

• A readiness assessment should be conducted on the customer prior to 
bidding a significant project. Elements to be assessed should include: 

- executive commitment to the solution; 

- user and management commitment to the solution; 

- adequate funding to cover all internal as well as external costs; 

- internal resource skill level and availability; 

- adequate infrastructure to support the new solution; 

- business process change requirements and adequate time to implement 

necessary changes; and 

- conflicts with busy seasons which may affect internal resource 

availability. 

• Share the results with the customer and attempt to develop an action plan to 
address any identified concerns. 

• At the commencement of every project, ensure that the I BM Project Manager 
reviews the SOW with the Customer Project Manager and obtains full 
concurrence regarding the tasks, IBM and customer responsibilities, 
deliverables, completion criteria, schedule, project organization and roles, etc. 

• Require the customer to report status on its responsibilities to help ensure 
project stays on track. 

• Include the customer in the project planning sessions to help create the Work 
Breakdown Structure. Here the customer's specific tasks will be identified and 
it will assist the customer in knowing their responsibilities as well as requiring 
them to assign resources to tasks. In turn, this will help the customer 
determine the workload for their resources. 

• Create a proposal for IBM or a subcontractor to perform the work for the 
customer. In some cases this may be enough to make the customer realize 
the need to take action. 

• Propose to charge the customer for IBM time lost due to customer delays. 
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5302. Customer unprepared to support the new system 

Description: 

Customers are sometimes resistant to accepting a system if their staff is unable 
to effectively support it. As a result, they keep IBM on-site to support the new 
system by delaying acceptance. 

Prevention Measures: 

• Include the appropriate level of training tasks to enable the customer to 
support the system in the SOW. 

« Include a post implementation support task to keep the system running while 
the customer's personnel become trained to support the system. 

• Include specific completion criteria in the SOW and in the project plan. 
Maintain customer's focus on the project completion right from the beginning 
of the project. 

5303. Customer represented by Third Party 

Description: 

Some customers choose to use a third party vendor to negotiate their services 
contracts. These third parties are given the mission of choosing a vendor to 
deliver a particular project - usually awarding the contract to the vendor that can 
deliver the protect for the lowest cost. These third parties are also given the 
responsibility to negotiate terms and conditions of the contract. Unfortunately, 
the vendors (including IBM) usually don't have any direct contact or involvement 
with the customer. This makes it extremely difficult to fully understand the 
requirements that we are being asked to bid on - or to help the customer 
understand why the value IBM can bring may be worth a higher price than our 
competitors. 

Prevention Measures: 

• Determine first if award is based on price alone. If so, be very specific in what 
Is not Included in the SOW and document all assumptions in the SOW. 

• Be sure not to price in any product or service that is not explicitly required 

• Implement Change Management at the first opportunity. 

• In the event that IBM is the Prime, request and validate the viability of the 
third party's detailed project plans and schedules and how they integrate into 
the overall IBM solution. Highlight and escalate to the customer any issues 
and areas that require further clarification as to the scope of the third party 
effort, as soon as possible and seek resolution. 

• Contact other proposal leads who have had experience with the third party to 
develop a plan for addressing the third party's requirements. 
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5304. Change In customer management team 

Description: 

Occasionally there are changes in the customer's management team which can 
impact the success of the project. This usually is the result of the new 
management wanting to evaluate all open projects and modify their scope to 
address the business issues that they want to address. It may even mean the 
termination of a project. 

Prevention Measures: 

« Ensure appropriate language is incorporated into the SOW to protect IBM 
from delays outside of IBM's control. 

• Ensure appropriate language is incorporated into the SOW to protect IBM 
from early termination. 

• The signed contract should have precedence, regardless of any changes to 
the customer management team. In the event that changes are requested 
from the new management team, the normal Change Control process is in 
effect. 

• The Project Executive should contact new management to determine their 
business objectives and strategy. 

« Develop an IBM response or proposal which meets the requirements of new 
management. 

5305. Ineffective relationship between IBM and customer 

Description: 

An ineffective relationship between IBM and the customer often is the result of a 
troubled project. It can, however, be the cause of a troubled project. In some 
situations a customer chooses IBM for a project even though IBM is not their 
"vendor of choice." Or the decision to use IBM was not the customer project 
sponsor's choice. In these situations the customer is often difficult to work with 
and can even try to "sabotage" the project. This obviously has a negative impact 
on the project's success. 

Prevention Measures: 

• Identify customer expectations and measurement for success as early as 
possible in, or preferably before, the project implementation. Determine 
customer's requirements for what meets minimum expectations. Set short 
range (one or two day) goals, and report on progress daily to establish 
successes early in the project. Under promise and over deliver wherever 
possible. 

• Escalate issues such as these as soon as possible to the customer's 
executive management team. Solicit IBM executive management support in 
these escalations as necessary. 

• The Project Executive is the key to the relationship. Communication with the 
customer must continue to take place with emphasis on the causes of the 
problems and resolution. 
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• Contract with the Relationship Alignment Solutions group to address and 
improve the customer relationship. 

5306. Customer having financial problems 

Description: 

Economic conditions often cause customers to have financial difficulties, 
resulting in their inability to pay invoices promptly or in more serious situations 
the closure of a project. In these situations there is often little that IBM can do to 
prevent the problem, but there may be steps that can be taken to assist the 
customer through the financial problems. 

Prevention Measures: 

• Involve IBM Global Financing to investigate financing for the project. 

• Investigate deferred billing arrangement. 

• Decrease scope to reduce cost. 
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Subcontractor Issues 

5401. Unfulfilled subcontractor responsibilities 

Description: 

Many of the IBM proposed solutions are dependent on the performance of 
subcontractors. When IBM signs a contract with a customer, IBM Is on the line to 
deliver regardless of whether the subcontractor can ultimately deliver. 

Prevention Measures: 

» Thoroughly check references of the subcontractor for this type of solution. 

• Review the subcontractor's detailed project and staffing plans. 

- Require the subcontractor to provide detailed status reports and issue logs. 

• Monitor performance of the subcontractor closely. 

• Allow for resources, money and the time in the project plan for IBM to review 
and, if necessary, correct the subcontractor's work product before delivery to 
the customer. 

• Add schedule buffer to the customer contract to cover for delays and 
corrections in the subcontractor's work. 

• Develop a contingency plan for alternative resources and methods to back fill 
the subcontractor in case of default. 

• If customer requires IBM to use a particular subcontractor, IBM should try to 
include a clause which allows IBM to terminate the contract if the 
subcontractor is unable or unwilling to complete its responsibilities. 

• Ensure the subcontractor's SOW is: 

- consistent with the IBM customer SOW, 

- detailed enough for IBM to assess the probability of success, and 

- reviewed by IBM technical resources to assess viability. 

• Follow IBM procurement processes to engage subcontractor. Use nationally 
approved contractors where possible to apply leverage on poor performance. 

• If new subcontractor, or contractor required by customer, pay special 
attention to financial report provided by procurement. 

■ Request references and follow up with previous customers for level of 
satisfaction. 

• Ensure that the subcontractor project plans are detailed enough and the 
status reporting is frequent enough to provide the IBM project team with 
"early warning* of potential impacts to project schedules and costs, so that 
appropriate risk mitigation plans can be established and executed mitigate the 
exposures. 

5402. ineffective relationship between IBM and subcontractor 

Description: 

Situations may exist where the relationship between IBM and a subcontractor 
becomes ineffective. This usually occurs when the subcontractor tries to go 
around IBM and interact directly with the customer or when the subcontractor 
feels they are being treated unfairly by IBM from a financial perspective on the 
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project. The breakdown of the IBM / subcontractor relationship can be 
devastating to the success of a project. 

Prevention Measures; 

• Establish expectations on conduct and contractual obligations as soon as the 
subcontractor is engaged. 

• Advise the subcontractor of the legal issues involved in circumventing 
contracts. 

• Establish a win-win relationship with the subcontractor just as with the 
customer. 

• Ensure regular meetings are held with subcontractors to ensure issues are 
addressed and early warning on problems is obtained. 

• If possible, ensure alternate suppliers are available to perform the services. 
IBM resources may be an alternative if problems arise. 

• Enforce terms and conditions of the contract. 



5403. Subcontractor cost overruns 

Description: 

It is often necessary to involve subcontractors on projects to supplement the IBM 
skills required to successfully deliver a project, tt is mandatory that a 
Subcontractor SOW be agreed to and signed by both IBM and the subcontractor. 
This SOW should include estimates for providing the tasks and responsibilities 
assigned to the subcontractor and should be agreed to by both parties. There 
are Instances, however, where these estimates are not accurate and result in 
overruns by the subcontractor. 

Prevention Measures: 

• Ensure that a Subcontractor SOW is agreed to by both parties. 

• Ensure that the subcontractor was involved in developing the estimates and 
agrees to complete their tasks within the agreed-to estimates. 

• Include clauses in the Subcontractor SOW to hold the subcontractor 
responsible for their estimates and protect IBM from cost overruns. 

• During the engagement phase, thoroughly assess the capabilities and history 
of the subcontractors being considered. Identify their strengths and 
weaknesses and assess what level of assistance / support from IBM may be 
required to address those weak areas. These weak areas could be in project 
management, development, testing, etc. and will sureyl be highlighted during 
the execution of the project. If not addressed, they will be significant 
contributors to the cost overruns. 
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Internal IBM Issues 

5S01. Problems with OEM or IBM products 

Description. 

Several bids have been based on the assumption that an unannounced or new 
product would work in a new environment. However, it is sometimes the case 
that the products do not work as anticipated. In addition, certain IBM and OEM 
products are prone to problems if not properly used. Quick and adequate 
response from the product labs or third party manufacturers is not always 
possible or forthcoming. A product need not be unannounced or new to cause 
unexpected problems in an integration project. There have been situations 
where products have been generally available for months; however, they did not 
integ rate into a new environment as expected. 

Prevention Measures: 

■ Perform IBM Product Reviews 
« Perform IBM Product Safety 

• Perform Technical & Delivery Assessment as required by the WW OA 
Process. 

• Conduct due diligence by modeling and testing the components to validate 
that they will work in the target environment. 

• The IGS Product Review Trigger Tool should be utilized to determine if the 
defined solution contains a product or products requiring an IBM Product 
Review. See Section 2 of the OA Information database for a link to the 
"trigger tool" and more information on the Product Review process. 

• Obtain a written commitment from the product lab or product owner outlining 
Ihe level of support, cost and/or liability coverage you can expect to receive 
should problems arise with the product during the project. 

• Set appropriate customer expectations. If new or untested components are to 
be integrated as a part of the solution, the customer should understand that 
there will be risks of delays in the integration effort. If a customer wants 
100% assurance of a fit, then a fulty-tested solution of standard available 
products should be proposed. 

• If the customer wants leading (bleeding) edge components, then the 
customer should be made aware that a certain level of risk is inherent in 
implementing a solution in an untested environment. 

• Conservative schedules and estimates should also be used to cover the 
unanticipated delays which invariably arise. 

■ Be prepared to propose an alternate solution if the components do not 
integrate as expected. 

• Avoid the use of new products in an untested solution. 

• Increase the risk rating of the project and include appropriate cost and 
schedule allowances for risk response. 

• If the new system is to replace an existing system, do not plan on an 
immediate cut-over. Plan for a pilot phase where both systems can run 
concurrently. 
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DOUs / Agreements should be drafted and agreed to by IBM and the 
respective OEM and IBM Product Labs / Support teams to provide timely 
support in problem identification/resolution of any problems found related to 
their products. 



5502. Technology / architecture Issues 

Description: 

In some situations project teams may uncover bugs or problems with existing 
IBM technology and/or architectures that impact the success of their project. 
This is different than #5501 which Involves relatively new products. This root 
cause Involves products that are not new. 

Prevention Measures: 

• Conducting the Technical & Delivery Assessment with the appropriate SME 
knowledge, experience and skills. 

* In the case of problems found In existing products, me Project Manager must 
ensure the appropriate process is followed for reporting the problem. When 
schedules are impacted, escalation must occur. On-site support from the 
product house should be requested to resolve the problem if normal methods 
have proved ineffective. On-site support should also be requested for key 
testing points on the schedule if additional problems are expected or critical 
situations are possible. 



5503. Failure of IBM to fulfill responsibilities with customer or other IBM 
organizations) 

Description: 

Under certain circumstances and situations IBM fails to fulfill responsibilities to a 
customer, mainly because one IBM organization has failed to fulfill its 
responsibilities to another IBM organization in delivering the contract. This 
generally occurs when one IBM organization is acting in the role of service 
provider whereby they do not own the contract and are working for recovery, not 
revenue. The other organization owns the contract, has direct responsibility for 
the delivery of the contract to Ihe customer, and receives the revenue for the 
contract. Too often, the service provider resources are "pulled" to work on a 
revenue contract for their own organization without fulfilling their responsibilities 
on the other contract. 

Prevention Measures: 

« Ensure a Document of Understanding (DOU) is agreed to between IBM 

organizations to clearly define expectations and time commitments. 
■ Secure executive sponsorship at the beginning of the project at a level lhat is 

sufficiently high to endorse any commitments. 
• The same expectations and criteria that we communicated to our 

subcontractors must be applied to our IBM subcontractors, with the same 

level of due diligence exercised. 
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• Certainly there have been problems with this type of IBM interaction, and the 
parties in revenue sharing projects can forget their focus and create parochial 
issues. The project lead must recognize this early and take steps to resolve 
the underlying problem(s) before the customer is impacted. 

5504. IBM project team morale or organizational Issues 

Description: 

Team morale and organizational issues can often impact productivity and 
performance on a project. This is especially true when project resources are 
expected to work extraordinary amounts of overtime due to poor project 
estimating or lack of proper change management. This is especially true when 
they get no utilization credit and are not allowed to bill for their extra hours in 
order to keep protect costs contained to the original estimate. Olher factors such 
as unclear project definition and requirements can also impact the morale of the 
team. 

Prevention Measures: 

« Ensure that all team members are aware of the project requirements and 
expectations. 

• Have project resources charge all time to the project - even though it may not 
be billed to the customer. This may impact gross profit, but team members 
will get utilization credit for the hours worked. 

• Execuie the change management process for changes in scope so that team 
members aren't expected to deliver additional work for no additional hours. 

• Provide some team-building activities (dinners out, night at the movies, etc.). 
This only takes a little money - but can go a long way in keeping the 
resources on the project happy. 



5505. Ineffective relationship between IBM organizations 

Description: 

With large complex projects it is often necessary to involve resources from more 
than one part of IBM. Performance targets and measurements are usually 
different and this often results in conflicts within the project team. Even worse, 
the customer frequently becomes aware of this internal conflict and then has the 
impression that IBM resources working on their project are not one team. 

Prevention Measures: 

• Be sure that Documents of Understanding (DOUs) are written between the 
groups to validate expectations, roles & responsibilities, and commitments. 

• Conduct an IBM team meeting prior to work beginning at the project to ensure 
that all parties understand the project organization, roles & responsibilities, 
tasks, deliverables, completion criteria, etc 

« Secure executive sponsorship at the beginning of the project at a level that is 
sufficiently high to endorse any commitments. 
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• When two or more IBM organizations are working together on a single 
project, ensure there is an integrated plan and a single interface to the 
customer. 

5506. IBM / Third Party alliance Issues 

Description: 

Some projects require the use of software, hardware, or sendees personnel from 
third party suppliers with whom IBM has an alliance. These are typically our 
formal "business partners" and not simply subcontractors. There have been 
situations where associates from the third party alliances have bypassed IBM 
and tried to interact directly with the customer - even trying to convince the 
customer not to use IBM on the project. This causes a great deal of problems on 
the project and can impact customer satisfaction. 

Prevention Measures: 

• Establish the project roles & responsibilities for the project very early - even 
before the contract has been signed, if possible. 

• Conduct a meeting with the third party alliance team members prior to 
meeting with the customer to establish the "game plan' for the project and get 
any issues resolved prior to starting work at the customer location. 

• Develop a well-defined communication and escalation plan. 

• Escalate any issues that surface immediately so that they can be resolved 
before the customer realizes there is a problem and Ihe project becomes 
troubled. 



5507. Multlslte development Issues 

Description: 

For large, complex projects that require a large number of developers and/or 
delivery personnel, it may be necessary to involve resources from several 
different locations. This makes the project much more difficult to manage 
because procedures and processes may vary by IBM location. Communication 
is often more complicated when multiple locations are utilized. 

Prevention Measures: 

• Try to contain all work to a single IBM location. 

♦ If necessary to use multiple locations, try to assign groups of related tasks to 
each different IBM location. 

« Establish a clearly defined communication and issue escalation plan at the 

beginning of the project. 
« Subcontract Management disciplines and procedures apply. 

5508. Offshore development Issues 

Description: 
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In some situations IBM may decide to use development resources that reside in 
a different geographical location than where the project is being delivered. 
Managing a project in these situations is often more complex because of time 
zone, language, or cultural differences. 

Prevention Measures: 

• Establish a detailed communication and status reporting plan at the beginning 
of the project to ensure that the project manager and remote developers are 
kept informed of work activities and issues. 

• Conduct regular status calls {not just written status reports) to validate cunent 
status. 

• Any work done offshore should have an interface person or project manager 
in the country contracting for the work. This will provide face time with the 
solution designers and end users to ensure the requirements are clearly 
understood. This person can then communicate to the offshore project 
members. They, in tum, will have a person who can answer questions or 
resolve issues who is familiar with their environment and the requesting party. 



Prevention Measures to Avoid Troubled Projects 



Page 50 



No Signed Contract 

5601. Working without a signed contract or PCA 

Description: 

In many situations the customer is anxious to get their project started and asks 
IBM to begin work while still negotiating the SOW. In these situations IBM is 
often anxious to satisfy the customer's request and keep them happy. So the 
project team begins work without a signed SOW or contract. Beginning work 
without a signed SOW or contract exposes IBM to potential toss of revenue for 
work completed in the event that contract negotiations are not completed and a 
contract is not signed. There can also be insurance and security exposures for 
IBM associates working at a customer location without a signed contract. 
Working without a signed SOW or some other contractual document SHOULD 
NEVER BE DONE. 

Prevention Measures: 

• Prepare an IBM Letter of Authorization (LOA) that officially lets IBM start work 
on a project while the SOW or contract is still being negotiated. The LOA 
must be reviewed / approved by Quality Assurance prior to being given to the 
customer. 

• Ensure that no project team members are allowed to begin work until the 
SOW or LOA has been signed. 
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Basic Concepts of Project Management 



Module X Team Exercise: 

Applying the Seven Keys Assessment 






m 



Module X - Team Exercise 

Applying the Seven Keys to the Olympics Case 



■ You're approaching the end of the project and a full review will 
be held soon. In order to facilitate executive insight into the the 
project you will prepare a 7 Keys Assesment. 
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Module XI: 
Closing the Project 





Objectives 




At the end of this module, you should be able to: 

■ Identify closeout activities 

■ Prepare a closeout plan 

■ Develop and apply lessons learned for future projects 
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Why We Do Project Closeout 



■ Closeout is necessary to ensure: 

- Client / project sponsor formally accepts the project 

- Project records are completed 

- Completion criteria are met for the final revision and issuance of 
documentation 

- Essential project documentation is retained 

- A lessons-learned document is prepared 

- Warranty is transferred, where applicable 

When do we start closeout ? 

■ On day 1 of the project - meeting with the client / project sponsor 

■ Closeout plan is part of the project control book (PCB) 
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Final Project Review 

a Ensures that all contractual obligations (suppliers and client / project 
sponsor) have been met 

■ Do before the project ends to ensure that the project can and should end 
• Prepare a report based on the reviews 
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Closeout Plan Implementation 



« Review closeout plan with client / project sponsor 

■ Implement closeout plan 

■ Prepare a checklist 



CbSAOul 
nwfltkng 



Proved 



plan 



Parson 10 
report* 



ChajgeatriM 



CoOod 












Final report 



Compliance. 
ttocunwKs 



Final payments 



Fodliry 



E<|i4>fnent 
malerlel 
disposal 
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Lessons Learned 



Timely 
Relevant 
In context 
Detailed 
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Key Messages for Module 1 1 



■ Project closeout begins on day one of the project meeting with the client 
/ project sponsor 

■ Closeout is necessary to ensure that: 

- Client / project sponsor formally accepts the project 

- Various project records are complete 

- Completion criteria are met for the final revision and issuance of 
documentation 

- Essential project documentation is retained 

- A lessons-learned document is prepared 

- Warranty is transferred, where applicable 

» The closeout plan is part of the PCB; it should be reviewed with the client 
/ project sponsor 

■ Actual closeout should be planned and budgeted just any other phase of 
the project life cycle 
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Basic Concepts of Project Management 



Module XI Team Exercise: 
Closing the project 





Module XI - Team Exercise 
Closing the Project 



Write the top 5 lessons learned for this project 
Each team will present 3 of them to the class (one related to 
one or more of your subprojects, one related to "soft" aspects 
of the whole project and the third one related to the "hard" 
aspects of it). 

Hint: Follow the Barcelona model for the document 
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Wrap Up 
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Objectives 



At the end of this course, you should be able to: 



Use project management skills across AMS 

Build your project team 

Prepare a useful team charter 

Identify and validate your project requirements 

Manage transformation of requirements into specifications 

Use change management to control requirements 

Prepare a Work Breakdown Structure (WBS) 

Prepare a risk management plan 

Establish a project estimate 

Compile and manage reliable network schedules 

Develop and manage project baselines 

Use project management skills and processes to contol project 

execution 

Prepare and execute a project closeout strategy 
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Objectives 



and you should be able to: 

► Apply Leadership concepts and techniques 

► Use PM oriented Metrics 
Operate at a proper CMM level 
Identify and apply all needed Business Controls 
Use GS Method, Knowledge Management, Intelectual Capital 
Management, GS Risk, XSER, PCB, PM Office and CLAIM. 
Understand and use the proper Procurement Administrative Circuits 
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Course Wrap Up 



Any Final questions ? ? ? 
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Test Protocol 



° 1 - Clear everything off the desktops and remove all charts from the 
walls 

■ 2 - Use pencil - mark clearly your choice for the correct answer 

■ 3 - Remain seated until is your turn at the grading desk - one person at a 
time, please 

■ 4 - Once you receive your results, please leave the room 



I Basic Concepts at Project Management. 





Course Wrap Up 



Best of luck !!! and thanks 
a lot for your attendance 
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Glossary 



lerm 


National 

Language 

Term 


Definition 


ABC 




activity-based costing 


Abilene Paradox 




Recognition of the fad that it is Just as difficult for people to manage 
agreement as it is to manage conflict 


accents nee' 




Ackrwwtadgment from the sponsor to the delivery nmiwijiitim or from 
the delivery organization to a Bffifiiifif that a deliverable satisfies the 
acceptance criteria specified in the agreement 






Written evidence of acceptance is generally required. 






Where a deliverable is subject to acceptance defined in an agreement, 
the set ol conditions that Ihe dettverabla muni rn»i m irt. rv» itw> 
deliverable to be accepted 


accounting 
equation 




Assets = Liabilities ♦ Owners' Equity 


acquisition 




The act of becoming the ovmar ot certain property; the act by which one 
acquires or procures the ownership rights in anytrtno. 


acton 




A unit of work that must be performed by the project thai was neither 
ii oi me pqm wdtk piane nor or suTTrcrani impact to warrant a 
change to the project management schedule. 

Actons can be initiated for many reasons, such as a corrective action in 
response to a compliance issue or a risk planning action in response In a 
nsk being identified. 


action control 




The rJocument that describes the actions and links them to their related 
issues or to other events requiring action m order to support 
c^anrmation. launcriing, oiickmg an acton This is a WWPMM 
work product. 






The list identifying all actions. Ihe owner, due data, and status 
TJiu is a WWPUU PU Work Product. 


manaoemern 




The processes dealing with assessing, assigning and launching, 
tracking, validating effectiveness, and closing actons. 






Generally, an elemont of work to be performod during the course of a 
project 

More specifically, in the context of a work breakdown stnirii m> organized 
by Phase •> Activity -> Task, an activity Is an element of work at a 
particular hierarchical level. 


tcttYlty type 




A classification of activities such that activities of me some type are 
assumed to have the same objective and content <e g., performing a 
preliminary interview) and to reojLCra tho same amount of effort from the 
same resource categories Activity types often describe the technique 
used for estimation. 
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Glossary 



Term 


National 
Language 

Term 


Definition 


actual cott of 
BflKB 




Total costs incurred for a pfO|BCt. Butj-oroi&ct. dafrvemble. or activity in 
accompttsfilng work during a given period of lime. 

In WWPMM. ACWP is calculated In two ways: 

* In tftrtTrt Of rWirft tlMtAsVafltVi 

* III U(N Via JM I MUl B *J A^rv' "J ^K*J , 

* tn terms of monies spent. 
ISee also earned valuel 


.clual damage 




The real, measurable, out-of-pocket costs recoverable as rxmpensation 
for actual loss 






Measurement of real evidence, as opposed to forecast. 
(See also forecast) 


ACWP 




actual cost of work performed 


AD 




application develop mart 


admin mr^tfYO 
closure 




Generating, gathering., and disseminating Information to formalize project 
completion. 


AECI 




aitreemcnl for exchange of confidealuu information 


agency law 




Lew that aflowa one party, called the principal, to delegate authority to 
another party, called an agent, to act In at) matters relating to Ihe 
business of Ihe principal . 


agent (or ISM) 




principal at e specified place and tne. 






Used In a generic sense to cover any tamalization of mutual 
commitments among parties WWPMM addresses specifically the 

between the delivery organization and a suDojjej., 
The term agreement may cover 

• A legal cojjjzflci between two distinct enterprises or organizations. 

• An internal agreement between two parts of the same enterprise or 
organization (for example, a document of understanding or a plan 

NOTE: The term agreement Is stso used to describe the initial 
agreement phis the sum of all amendments to date. 

This is 8 WWPMM PU Work Product. 






Performing those activities required to conclude the agreement. 
Agreement completion typically signals the end of the temporary 

obligations of the agreement have been satisfied. 


ALAP 




as late as possible 
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Glossary 



Term 


National 

i ttnmintMt 

s * * '<yu %m £f\s 

Term 


Definition 


altruistic- 
nurturing 




Ljiaraciensoc or an inunrauai concenwu wim ins piuietuw, yruwnn, wiu 
welfare of others. 






A formalization of changes to the agreement. 

NOTE: This term is used in WWPMM to indicate a change to an 
agreement that is already in place, not those items that might be included 
in the original agreement as "amendments,* such as changes to standard 
terms and conditions 

msisa WWPMM PU Wot* Product. 


analogous 
estimating 




Also called top-down estimating: using the actual duration of a previous. 
Similar activity as the basis tor estimating the duration of a future activity 
(PMBOK*63.2.2andT221) 


analytic- 
outonom bring 




Characteristics of an individual concerned with planning and is fair and 
principled 


analytical aktlla 




The power to simplify what Is either complex or complicated. 


AQA 




activity-on-arrow 


application 




■ A combination of programming and data that performs a useful function 
on behalf of users 

• The use to which a data processing system is put. II includes 
convantional applications, such as stock control or credit checking and 
also less tightly controlled environments such as a QMF service or 
spreadsheet, or management functions such as capacity planning or 
software distrtbutkm. 

Applications may consist of standard products, custom-butt programs, or 
a combination of both. 

Application data is always unique to the installation. 


UDraYslte 




Authorization from IBM management and/or the protect sponsor, 
depending on Ihe type of prefect and the point in time , to proceed with 
the next stage of the project 


arbitration 




The process of settlement of a dispute between hue parties by an 
impartial third party. NOTE: IBM generally will not accept arbitration 
clauses in either dient or supplier contracts. 


AFP 




automatic register pickup 






The point in time relative to which data is defined as actual (historical) 
data or future (scheduled) data. For example, costs as of September 
1999. 


ASAP 




as soon as possible 


ASPECT 




Automatic SPEctab Card Tester 


aspiration 




A strong desire or edition, as tor advancement or honor. 


essorthre- 




Characteristics of an individual ooncemed with task acoarnplisnrneru 






Ail items of value owned by a company 






The transfer of a right, a contractual obligation, or property from one 
party to another Example: Under the International IBM Agreement, the 
client agrees not to assign its rights, delegate its oblige torts, or resell any 
service without IBM's prior, written consent 
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Glossary 



Term 


National 
Language 

Term 


Definition 


assumption* 




Factors that for planning purposes wit bo considered to bo true, real, or 
certain (PMBOK* 4.1.1 .Sk 






AnyBting otal attaches a thing to another. To make a thing part of. In 
contract low. usually a document attached to the base agreement that 
further explains, modifies, or supersedes certain aspects of the base 
agreement. 












A systematic and Independent examination to cetermlna whether 
aanrMi and related results comply with planned arrangements, and 
whether those ajrar^emeritB are implemented effeebvety and are 
suitable to achieve objectives. (From ISO 8402) 

An audit focuses on analysis of evidence, followed compulsory actions 
while an assessment Is en appraisal with recommendatory 

(See also review) 


autfiorUftd 




The only people who can make, accept, reject, defer, or negotiate 
change. 


•rwtxn} 




The act of granting or assigning a contract from a buyer to a seller 


SAC 




budget g» comoleuon 


bankruptcy 




ihe state of being Insolvent: failure or inability to pay Just debts or 
obligations. 


bar chart* (gantl 
charts) 




Show ecovfty start ana end dates and expected durations but do not 
usually show Dependencies (PMBOK* 6.4,3.1). 


lamiji 




The reference data on which execution of project activities la continued. 
It consists of elements of the anreernerit and the orolect manaonmftnt 
etana. Ones established, the basedna la under chanoe control. 

Wren used with a modifier, the term defines a subset of the overall 
baaeDne such as tta hAMllnm 

[See etso orolect mananoniont nlnno 


BCR 




beneflt-coet ratio 






Anything accepted as true; a creed, doctrine, or tenant; an opinion, 
expectation, or judgment 


benefit-cost 
analyala 




Estimating tangible and intangible coats (outlays) and benefits (returns) 
of venous protect attemabVos and using financial measures such as 
return on Investment or payback period to assess the retativa desirability 
of the identified alternatives (PMBOK* 5,2.2,2) 


best snorts 




A statement in e proposal or contract that implies that the buyer or seller 
will put forth Its best skills end dedication with the intent of meethg an 
obligation. 


best estimate 




The estimated coat of a project based on the currently known facts 
repenting scope, schedule, and expectations. See bme-and-malerlals 


bid 




An offer to perform a contract tor work Would Include tabor and/or 
supplying materials or goods and/ or services at specified price. 


bid bond 




A monetary guarantee that the bidder, if awarded e contract, will in fad 
execute (sign) it. NOTE. A bid bond expires automatically at Ihe time Ihe 
contract is stoned b» the partes, or tt Ihe contract Is not awarded. 
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Glossary 



Term 


National 

Language 

Term 


Definition 


BMWB 




Business Management vYorkBencti 


bond 




A monetary guarantee to cover losses suffered for specified reasons, an 
obligation or constraint. See also bid bond; performance bond. 


bottom •up 




Estimating the cost of Individual work items and then summarizing or 


broach of 
contract 




Violation of a contractual obbgabbn. either by failing to perform one's own 
promise or by Irrierferinfl with another party's performance. 


BRS 




Business Recovery Services 






The total amount of labor hours and/or monies allocated for a specific 
purpose during a specific period. 

Usually used With a modifier (eg.. project auh-nmlnnt activity or 
deftverabtel 

NOTE; Budget in terms of monies can be calculated m various ways and 
care must be taken to understand the basis of Ihe calculation (e.g., using 
standard labor rates and costs, using discounted tabor rates and costs 
using average labor rates and costs). 


budget o Estimate 




(See estimatal 


budget at 
(BACI 




The estimated total cost of the project when done. 


budgeted cost 




fSaabudoetl 


budoeted coat of 




The sum of the puppets for a nrolect. sub-project deliverable or activity 
completed during a given period (usually project-to-dale). In simple 
terms, BCWP is the costs that should have been Incurred for Ihe work 
completed to date. 

In vVWPMM. BCWP is calculated m two ways' 

• In terms of hours expended. 

• In terms of monies spent 

In addition, BCWP in terms of monies spent is calculated both for labor 
only and for labor plus all other costs. 

(See also earned vnjufl) 




IBCWP) 
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Glossary 



Term 


National 
Language 

Term 


Definition 


budgeted coat ef 




The sum 0) the button In for a protect. Eirb-orolect. netrvarabla or activity 
scheduled to be performed during a ghran period (usually 
pro^-to-date). 

In simple terms, BCWS la the costs Stat should nave been Incurred tor 
the work mat should have been compte led to data. 

In WWPMM, BCWS is calculated In two ways: 

• In terms of hours expended. 

• In terms of monies spenL 

In addition. BCWS In terms of monies spent is calculated both for labor 
only and tor labor plus all other costs . 


hminoii 




Business entitles that work In dose association tor a common objective. 


bualnaaa pjjjd. 




Problem or chetenge faced by the project sponsai or a subset of the 
market that can be partially or wholly addressed by the inmat ablution 






One ol thrae tvoes of health revtew oefinaa In WWPMM 

A review thai focuses on the state of the business as measured against 
elements of the project plan. Business reviews are conducted by IBM 
only and are outside the scope of WWPMM. 


business 
■Wane* 




Business entities that work in close association for a common objective. 






A business entity with a special relationship to a pmvapal, making it 
easier to iotnUv address a business opportunity. 


twy*f 






buyw't rtghl 




The buyer's power, privilege, faculty, or demand, Inherent in one person 
end incident upon another. 


MF 




best and final 


cartel 




A combination of producers of any product joined together to control its 
production, sale, and price so as Id obtain a monopoly and restrict 
competition in any particular industry or commodity. 






Computof-Alded Software Engineering 


££|E 




1 . Something that produces an effect or result (the cause of Hie 
academy 2. A around for legal action. 


CDRL 




contract data requirements list 


CEC 




IBM Corporate Executive Committee 


"glnslltv 




A written assurance, or official representation, of product or materials 
ownership. 






A formally constituted group of sJBhaJigUgsi responsible for approving or 
rejecting change requests 


change |m 




The list of all changes, the owner, due date, and status. 
This is a WWPMM PM Work Product. 
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Glossary 



Term 


National 

Language 

Term 


Definition 


cjuagi 
frHtnggofnejif 




The processes tor handling a change request to its completion. 
Execution of change management may result in change* to the 

baseline. 

Not used in WWPMM to describe management ol business or 
organizational changes. 


ChurBfi Order 




A directive to implement a change resulting from an accepted change 
igguesj. This is a WWPMM PM Work Product 


chanoo request 




A request to change some document or aapect of the project that has 
been placed under change control 

This is a WWPMM PM Work Product. 






ISea protect charter) 


checkpoint 
schedule 




A variation of operational schedule, used when the progress of the work 
is constrained by steps, each of which must be completed in order to 
Complete the work as a whole, and with which values of percent 
complete are associated. See operational schedule. 


ChM 




Change management PM domain 


CHQ 




corporate headquarters 


civil law 




The body of law created by acts of legislature and concerned with civil or 
pnvaie nun is aw remeuies. 


cianiyinfl 




U air in/* nr iM^wnirw, aa«kr Id , n nln, i In, 11 1 

Mmiqj or iMfuurriinu easier iu urmurousrKi. 






A turpi commonly used to refer to the customer in eervicas engagements. 
ISea customer sea also soon sot) 

NOTE: WWPMM generally uses the term 'customer- instead of 'client'. 






Communication between the sponsor and the dehvery organization, or 
between the deovety organization and a aujrpJiBL eckrowtodging that the 
agreernerit is completed. Provides evidence thai all terms of the 
agreement have been satisfied and aP work has been compietad. 

(See also administrauyfl doaura) 


CPFF 




cost plus fixed fee 


CPI 




cost performance index 


CPIF 




cost plus incentive fee 


COE 




center of excellence 


cohesion 




The act or condition of sticking together: Wending, or merging. 


CoM 




Comrnunications Management PM Domain 
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Glossary 



Term 


National 
Language 

Term 


Definition 


commitment 




1The process to obtain responses to bide from two or mors sources to 
purchase materials, goods, and/or services. 

2 The manner in which a project or product deliverable is measured 10 
ensure it meets the requirements tor acceptance as defined In the 
statement of work or requirements document 

3. Agreement or pledge to do something. When given on external 
contracts, commibnents are leoalty enforceable 


common law 




The body of those principles and rules of action that rjerrvetrv^ authority 
from tradition, usage, custom, and previous judicial decisions. 


common sense 




bound and prudent hidomaru 


communicating 




Exchange of Information (PMBOK* 2 4 2). 


communication 
requirements 




Sum of the Information requirements of the project stexenoUers 
(PMBOK* 10 1.1 1). 


communication. 

■na 




Document that describes the plan to moat the Information and 
communicationii needs (if RtnkehnMAm- that >« jv, - — >- 
information, when they wilt need It, and how they wSI receive it. 
This »s a WWPMM PM Work Product. 


co^nmunleaUq-j 
nlinnlgo 




Determining the information and communications roods of the nroiocl 
gJajBhoJdaa 


CMnmunkiMont 




The processes 

tnsure urrxwy ano appropriate coflocoon, p^rtargbon, dissemination, 
storage, and disposition of prqea ^formats* 

• Pmvida the mlif^Ql Hr^kc d rrwvi nil In utaae n**j4 ' t r " , 

i iviuo i/io uiuua wins among people, toeas, ano inTormauon that 
are necessary for success. 


competent 
panin 




Persona or legal entities possessing log* capaoty and authority to enter 


corapieilon 




Objective criteria by which it can be determined that an acovrty has hrwi 
compmted, usually related to the release of its associated work promts 
if any. 






A measure of completeness resulting from an anatytjca) assessment and 
s subjective assessment that describes the status of a wort, nnvt.rt 
flsttarjtojg orflfljaty,, The assessment addresses issues of cost, 
schadulg and Qualify. 


compliant 




Event In which the aBflQaflt or a s^^ la not rwiettng an obligation 
under the Bsr&emWll 


compliance, 

iDsSsttOL 

dnemwni 




A document that records the Information about an event in which the 
sponsor or s supplier is not meeting an obligation under the agreement. 
It contains the initial description, progress of resolution, and final 
assessment of damooe. This is a WWPMM work product. 






Tne l"1 o' compliance rnrirtwitu the sponsor or supplier Involved, the 
owners, due dates, and status. 

Tnii is e WWPMM PM Wo* Product. 



Underscore . WWPMM Terminology 

Currant version can be found at l>ap^iW3-a.lbm.oomrlr»nsromvpro(«cOT 



11)1}))) 



Glossary 



Term 


National 
Language 

Term 


Definition 


ST 




A renew intended to ensure that policies and procedures are being 
followed b, the project and to Identify improvements to procedures. 

Compliance reviews may be conducted by an IBM organization external 
to the project, by Ihe SBSIrSflr.. or by an outside body. 


component 
ooiiveraDie 




Any subpart of an irfermediate. Wgher-level deliverable with the 
attributes of a deliverable. 


composer 




A person who creates or develops. 


condition 




Component of a statement of risk; a single phrase or sentence Dial briefly 
describes the key circumstances or situations causing the doubt, 
concern, anxiety, or uncertainty. 


conTiaemtiai 
JntormatJon 
svchano* 




Legal agreement between two parties to exchange mforrnalion which is 
intended to be held in confidence or kept secret. 


ConManUaJJty 




State or quafify of being confidential; treated as private and not for 
publication. A special term and condition (n IBM's con tracts that covers 
the agreement on the exchange of confidential information between 
parties to e contract. 


confiaurmtepr. 




A WOfh product, work product component, or element on a firoducl 
breakdown strurtum Ihfti hi rim^naiori tn iw> pi»~*H ■ tMtr rnnfini imttnn 
management. 






The process of oefnoig. monitoring, and controlling the status and 
yempnj of the components of a system, which together constfbita a 
consistent whole far a period of time. 


conflict of 
Into rest 




Engaging or giving the appearance of engaging in any activities or 
advancing any personal interest at the expense of IBM's interest 


coraeQueftca 




Component of a statement of risk' n abieSe ohnm rv nmnim nut i™*. 

describes the key possible outcorne(a) af the currem condition a. 


corwoquanUai 




DamooGfl Ittat do not flow direrttu Anri 0rmwtwftAit>iu tWtm a** nt ™ 
party but only from some of the consequences or results of the act. 
Example: The dienfa point of sale system is down tor four hours due to 
a software problem. As s result, the diem claims to have lost hundreds 
of thousands of dollars due to lost sales. 


conaldaratk-n 




Somethino of value. 


SlitanMnt Facility 
{CSF) 




An IBM program that enables a customer Involved m a multinational deal to 
pay all He bdls centrally in one currency 






A group of people In a company or organizabon with a common set of 
characteristics, such as market segment, business model, geography, 
profession, and so on {e g.. Managed Opera txxs, Brands EMEA. 
Education Industry ) 






Factors that will iirrtl the project management team's options {PMBOK* 
4.1.1.4). 






Applies to EMwarti Paltfrm Slaps, briefly sunvriarizing what has to be 
done or considered by the project manager. This description provides 
context for the PM to appreciate the guidance given by the related 
processes. 

(See PM work rHllprn nun see also PM work pattern) 
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National 
Language 
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Definition 


aonttoaicai 

BtlD 






contlnQ#At tams 




Possible, but not Bsourod, conditions upon which the term is fulfilled or 
arxxrnpiisood. 


contra 

DT9 f g r% ft tAfTL 




Means thai en ambiguous provision is construed most strongly against 
the person who selected the language or wrote (he centra ct 






A legally binding form of commitment between parties. 
An IBM contract usually consists of 1 

• a base agreement that sets the basic terms and conditions, 

• attachments (e.g., amendments), specifying additional terms retail ve 
to specific details, including special terms and conditions. 

• transaction documents (e.g.. statements of work), which confirm the 
specific details. Including special tarms and conditions, relative to a 
perucuiBT uansacuun. 

(See also nlan contract, agree menu 


contract 
administration 




Process of ensuring thai the setter's performance meats contractual 
requirements (PMBOK* 12.5). 


ctx'.'ji ct 
authority 




Trie power that the principal confers on the agent to act on his or her 
behalf to enter into a con trad 


contract 
ctotoout 




Completion and satdamenl of ths contract, including resolution of all 
outstanding items (PMBOK* 12 8). 


contract law 
(Uniform 
Commercial 
Cod* (UCO) 




A model taw developed in the United States to standardize commercial 

fcnawtnwtiiv*, ftPTWwi ttwi (rtattxa 

*rV* HI fHUlB| QliaUliy U *U WOIH. 


contract 
ntanaootnont 




The process af planning, forming, and administering an agreemen! to buy 
and/or sell goods and/Or services from one party to another. 


contract 
negotiation 




Clarification and mutual agreement on the structure and requirements of 
the contract prior to the signing of the contract (PMBOK* 12.4.2.1). 


contract types 




The rmistamrnon contracts type Include; Flrm-fwed-price (FFP): 
FbtacS>rice-lncentive fee (FPtF); Cost-plus-fixed fee (CPFF); 
Cost-plus-incentive fee (CPIF); Timo-and- Materials (T4M); and 
Levet-of-effort (LOE). Ganeralty refers to how the buyer win compensate 
the seller. 


contractor 




One that contracts to do work for another. 






(See project control.) 
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Term 


National 
Language 

Term 


Definition 


wntfc-Ywilol 
detect 




A finding whose status is ambiguous. Trie finding is classified as a 
controversial defect until It can be agreed that it fatts into one of the 
following catogones: 

• not a defect (i.e., conforms). 

• other (such as a wish for future versions). 

Usually results from unclear or Incnmctata reouirements. soecifi cation a . 

dealing with such a situation must be negotiated with the sponsor or the 
supplier and may result in a change request (usually a scope change) 


VUlfwTllirIi 




The right to literary property, giving authors, composers, and other 
creators the sole right to reproduce and distribute their work for a limited 
period of rime. 






From ISO 8402. an action taken to eliminate the causes of an existing 
norwonforrnitv. defect, or other undesirable situation In order to orevenl 
recurrence. 

In WWPMM , corrective action is used more broadly to mean changes 
made to bring future performance of the protect into line with the OUfito 

system or yyoih nlsns. 


correspondence 
tog 




A backing list of the individual correspondences with identifying 
information such as sender, recipient, date, and category. This is a 
WWPMM work product. 






A time-phased budget used to measure and monitor cost performance on 
the project (PMBOK 7.3.3.1). 






Allocating the cost aftjfpqlpq to individual project components 






The process of comparing aaual costs witfi BJannsc] costs, analyzing 
Variances, evaluating possible alternatives, and taxing carre<*rm' potion 
as needed. 






The ratin of budgeted costs to actual costs 1BCWP/ACWP|. 

CPI is often used lo predict the magnitude of a possible cost overrun 
using the following formula: original cost estimaterCfl • projected cost at 
gompJetjon. 






A list and sum of cost elements showing the total cost for each category 
uf cost, such as resources, hardware, software, and so on over one or 
several periods ot time. 

This is a WWPMM PM VVor* Product. 


com variance. 




(1) Any difference between Ihe budgeted cost of en activity, end the 
actual coat of that activity. 

(2) In earned value. BCWP less ACWP 
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JVSErOfMI 
Lsngosge 

Term 
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com {or direct 
cost) 




The expenditure at tunas that result directly from production products 
and/or establishine an mfrastnjcture to provide services, A (direct) cost 
can be traced to the finished product or service. 


com baseline 




Tlme-prcasBd budget used to measure and monitor oost performance on 
the protect [PMBOK* 7.3.3. 1 ). 


com estimating 




Estimating the cost of (ho resources needed to complets project 
activities. 


COM of quality 




The coats incurred to ensure quality. The cost of quaflfy includes quality 
plannina. quality control, quatitv assurance, and rework. 


cost variance 

(CV1 




(1) Any difference between the estimated cost of an action, ard the 
actual cost of thai activity. (2) In earned value. BCWP less ACWP. 


Com 

rMmlHjfiofrMjnf 

co n tract 




A type of contract In which the seller gets reimbursed for coats of 
producing the Item. Also a category ofeontract types that includes 
ccst-rjus-incantrve-tee (CPIF). cost-plus-fixed-fee (CPFF) and 
cost -otuB-e ward-fee (CPAF). 


cost -pi tra- 
inee ntrve tee 
(CPIFl contract 




A type of contract in which the buyer reimburses the seiler for the seller's 
aflowable coals (allowable coots era defined by the contract), and the 
setter earns ita profit if It meats defined performance criteria. 


Co»t-Plus-Aw*rd 
F«* (CPAFI 




A type of contract In which the seller gels reimbursed for costs of 
producing the item and gets paid a fee for wuirtnq the contract. 


coat -plus-award 
fee ICPAF) 




A type of contract In which the setter gels reimbursed for costs of 
producing the item and pels paid a fee for winning the contract 


Coat-Plus-Fbed 
rss (CPFF) 
contrsct 




A type of contract in which the buyer reimburses the aatiar for tho sailer's 
atowabla cows (allowable costs are defined by the contract) plus o fixed 
amount of profit (fee). 


cc«t-pl us -fixed 
ISO IvrrrJ 
contrsct 




A type ofeontract In which the buyer reimburses lite seller for the seller s 
allowable costs (aUowsbte costs are defined by the contract) plus s fixed 
amounl of profit (tee). 


Cost-Plus -Inesnt 

IvsFm(CPIF) 

Contrsct 




A type of contract In which the buyer reimburses the Better for the seller's 
allowable costs (allowable costs are defined by the contract), and the 
seller earns its profit If II meals defined performance criteria. 


Cost Phis 
Psrcerrtage-of-C 
osl (CPPCI 




A type of contract in which the seller gets reimbursed for the cos) of 
producing the Item and also gats a fee calculated as a percentage of 


CPM 




critical path method 


CPU 




central processing unit 


CR 




cast reimbursement 






Decrease total project duration after analyzing alternatives to determine 
how to get the maximum duration compression for the least coat. 






In a project, nfltwnfti fllwram the series of actjyjtjss, which determine the 




eartesl completion of the project 

The critical path will generally change from time to time as activities are 
completed ahead of or behind schedule. Although normally csfculatad for 
the entire project, the critical path can also be determined for a milestone 
orasub-omlfid The critical path is usually defined as thoso acthifas 
with a fjgaj lass than or equal to a specified value, often zero 
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National 
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Definition 


critical path 
method (CPM) 




Calculates a single, determmrstk; a arty and lata star! and finish date for 
each activity based on specified, sequential network logic and a single 
duration estimate Float is calculated to determine whtcti activities have 
the least scheduling flexibility (PMBOK* 6.4.2.1). 


CRM 




Customer Ralabonahip Management 


CRR 




comparative risk ranking 


CS 




Consolidated Statement 


CSF 




Consolidated Statement Faotiry 


CUPRMDSO 




capability, usability, performance, reliability, instaUabflity. maintainabilrty, 
documentation, service, overall 


CUPRIMD 




capability, usability, performance, reliability, installabirlty, maintainability, 
documentation 


i 




i r*j uonvnry u» yaniziiuor s prefect, usually ntrerreo 10 ffl VVVVrMM OS 

sfrnotv "the nroiect * Mnv nnhr fwryvMta it (uih-ant r>r rtw ismai «niii4in«i 
which may itself address ontv a subset of the business nenri 






The recipient of a product or service provided by the delivery 
organization. The customer may be the ultimata consumer, user, 
beneficiary, or purchaser. (ISO 6402) 

In vWVPMM. the customer may also be the sponsor 


Customer 

nam 




One of two major corporate business processes (wtlh Integrated Product 
Dcvalorxnenl) within IBM. CRM defines standards tor how we respond 
to every customer, partxxilarty In the delivery of services engagement. 


cv 




cost variance 


damages 




Compensation recoverable for a wrong or an injury. See also actual 
damages; consequential rjamaoes; liquidated damages. 


DBMS 




Database Management System 


DCP 




decision checkpoint 






Process used to develop the PBSAVBS by suixlivirjing the major work 
products mto smaller, more manageabla components until each is 
defined in suffioent detail to support future project activities 


default 




The omission or failure to perform a legal or contractual duty; esp.. the 

fniliirrt to nAw A HnHt iUimi rfciA 
■mure iu tt&j uuui wrajrr uuo. 


dabcj 




Anasoectot a work prodqet or a ddjyefabta thnt rin«« n« n»«i a, 
intended purpose. 

In contrast to a ncn-cnnfnrmilv a iMnri ran ho waaan »« an in^., a «. 
with respect to Qgerjs or general expectations. 

In technical work, detect can also be the entry In a defect management 
system used to describe and track responses to the inadequacy. 

(See also controversial defect and latent defect! 


deferred 
payment 




The buyer's making payment to the seiler some period of time after the 
deliverable has been accepted for the crjnvenience of one or both of the 

parties. 


delayed 
Invoking 




The sellers invoicing the buyer soma period of Bme after the deliverable 
has been completed for the convenience of one or both of the parties. 
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A work product dm! must ba delivered accorttng to an aojBttpanJ, 

A work pnxhjcJ that Is not apocjfSod in an sgrsBmanl ta not nrforrod to as 
a qqmvvww. n is btmpfy a worn proeuw. 

NOTE: The WWPMM definition of deliverable Is much mora specific than 
wjiwiwi usage ifi some pans or ism, wnoru n s uvea us an oqurvuieTii (p 
MM product. 


dflllwrabtfl 

ccmppnant 




A portion of a Jjejiye^bj^ that is, itself, visible to the receiving 
organization. 






A description of a deliverable or flelhrerabtfl component together with its 
associated acoaplance crlterta and status Information. 

This is a WWPUU PU Work Product. 






A reiiflw. ol a deliverable or deWarasle component batore retoasing rt to 
the IRSOisI lo ensure that no open Items remain and that It is ready to be 
delivered. 


deliverables 




The management of the life cycle of deliverables from definition through 
acceptance. 


delhrary control 
docmnentjtlan 




A paper or etectrontc record from the delivery organization to the sponsor 
or to s supplier to furnish evidence of release, receipt, and/or acceptance 
of a deHvarable. This document has up to three components: a delivery 
notification, a delivery receipt, and an acceptance notification. 

This is a WAVPMM PU work pndudL 


delivery 




The organization thai enters Into an agreement with the ttaonaor and is 
responsible far meeting the obligations of the agreement 
The olivary organization is responsible for seltmg up the project team, 
may provide the top-level project manager (who vaD act on behalf of the 
delivery omanization). ensurtnc oomolation of defhierables. and raieasina 
deliverables to the sponsor. 






A list of the deliverable deftnUiona associated with orated milestones. 
The delivery plan is typically Included in the agreement or as a 

a sjrfloMi to the delivery organization. 






An Input/output and/or time-related relationship. A protect dependency 
exists between two proied elements (for example, actjvjft aub-oroiect. 
milestone!. An external dependency exists between the project and an 
organization, activity, or event outside the project 


depreciaUon 




A method that spreads the cost of a long-oved asset over its entire 
service life. 


derivative works 










iSee variance see also cost variance! 



1 Whan nnMWni mn ar» unguagM. th» tarm mu« l» nwtoC vary carefully, faktlaonal,. La uaa rrut M eorattsftl with local an. 
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Ton- 

1 vi in 


Definition 


dtaput. 




A conflict or controversy; a conflict of claims or rights; an assertion of a 
right, claim, or demand on one side, met by contrary claims or aOegabons 
on the other. The subject of litigation; the matter for which a suit is 
brought 


DM 




Deliverables Management PM Domain 


document*! 

understanding 

ICflUJ 




The name c<Kwnonty used within IBM for an agreement between two 
IBM organizations. 


domain 




ISnn pmfad management domain! 


duration 




Shortenino the project schedule without raducino the orojed oblectives or 
defrverables. Such compression increases risk, often increases cost, 
and may not be possible. 


duration 




The number of work periods (not tnctudmg hofdays or other norvworkirtg 
periods) required to complete an activity or other project element; usually 
expressed as workdays or workweeks; sometimes incorrectly equated 
with elapsed time. 


duration 




Shortening the project schedule without reducing the project objectives or 
deliverables. Such compression increases risk, often tncroases cost, 
and might not be possible. 


e-BIDS 




A tool, available from bw Global Customer Offerings (GCO) Web site 
that enables opportunity owners, cberu teems, bid managers, and oncers 
to work collaboratively to determine a price for a generally available 
product 


E-l 




Extra vert -I n trove rt 


EAC 




estimate at completion 


earty finish (EF) 




In the critical path method, the earliest possible point in time on which the 

in H iMiiiMWlml mtiiHH nt an artHiih* frw Hin im ifai 11 ran finion hoonri m 
u'wi^ww ^kjww mi aji tnAivity tm miw^m**/ vwi iwi iwiw km i 

the nehvork logs: and any schedule constraints; early finish dates can 
change as (he project progresses and changes are made to the project 
plan. 


uny sttft (E3) 




In the critical path method, the earliest possible point in time on which the 
uncompleted portions of an sctMty (or the project) can start, based on 
the network logic and any schedule constraints; early start dates can 
change aa the project progresses and changes ere made to the project 
plan 


^fifijfjjya 




The budgeted cost of work performed for an activity or group of activities 
schedula^budpaTod m^^oi^a»rtoim^^^^''c%t 


index.) 


EC 




endneering change 






The process of comparing actual performance with planned pertormance 
using flarrifld yajue as the method for moasunnq project perfomvance. I 
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National 
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education ajaj 




A description of project -related training planned tor individuate or human 
resource catsonritm assigned to a projaci. 

Trie education ptan Is a part of the humnn r» m ,rr» nUn. 


education 




Process of training and developing knowledge, skills, and character by 
formal achcotinfl. 


EF 




Early finish 






The number of labor units required to complete an actjvfly or other 

Usually expressed as staff hours, staff days, or staff weeks. Should not 
be confused with duration.. 


elapsed time 




Number of calendar days over which the task occurs. 


Compatibility 
[EMC) standards 




National and Ifl tUl 1 m f innnl alfliwrai'ila thai ihm— fit>i f, iiiii ii i Hi [■ i l 

<n^i mi«Tiawiei ««"»nn mat govern electromagnetic tfilerrerence 
of electronic devices. 


EM 




Event Manauement PM Domain 


EHEA 






emotions! 
leauei: csums 

Of self-Oriented 

•moUonal 
behivlof 




Behaviors displayed by Individual team members sometimes at the 
expense of the rest of the team and its objectives. 


Enhanced Cost 
Recovery (ECR) 




A business management system used to motivate local countries to 
support a multinational project ECR provides a method for giving a 
country or IBM organization s cos! credit {of about 25 percent) for 
measurement purposes when lending staff to another country or 


entrepreneurial 




Orgaiwina and managing a business undertaking. 


•cults bl. 
treatment (of 
suppliers) 




Just, conformable to the principles of ojstice end right m which suppliers 
are treated. 


participation 




The extenloi an ownership Interest in a venture. 


ERISA 




Employee Retirement Income Security Act 


ERP 




Enterprise Resource Planning 


ES 




early start 


escrow 




The deposit of something mto the care of a mutually agreed upon 
custodian for delivery to the grantee on some defined set of conditions. 
NOTE: IBM win absolutely not agree to put into escrow the source code 
lor any of its licensed programs. 
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Glossary 



Term 


National 

Language 

Term 


Definition 


estimate 




An assessment of the likely quantitative result based on experience 

Usually applied to effort, project costs (labor hours anoVor monies) and 
durations, and should ideally Include some indication of accuracy (e.g., 
phis or minus x%) Usually used with a modifier (e.g.. preliminary, 
conceptual, feaslOUUy), 

Contrasts with £fiffl£flaL which n based on experience and data from the 
Currant project 


estimate at. 
completion 
IEAC1 




The expected total cost (labor hours and/or monies) of an asSMu!, group 
of activities, or the nkaa when ttie plan^ work has been completed. 
Most techniques for forecasting EAC include some adjustment of the 
original cohi esnrtntg based on project performance to date. Often shown 
as EAC = actuatB-to-data ♦ ETC. 

earned vahie. estimate to complete) 


«mplttofETC> 




The expected coal (labor hours and/or monies) needed to complete what 
remains to be done when en activity or group of activities has been 
undertaken. 

Most techniques tor forecasting ETC include some adjustment to the 
original estimate based on project performance to date 

(See also Mmfid ya|ge, BStimBIS at wmrtotfon oa™nl cnmojejej 






e> PeMffWin a twTkta /if swHiuiKj rv fraaeylr 
r • ajHaWlll a tJT^Kt <J1 oC^YHy Of la 3ft. 

• Create a tvw of PBS element 

A cjarsHanrl OtBrimOilirui hnna in maaIaiI k., - ■ — ! _-._m._j k 

m sianoaro esumsung oasis is created By measuring and averaging real 
efforts overtime. This NstoriceJ value is used to produce an estimate 


ETC 




estimate to complete 






Ketatea to ma manner m wtucn individuals perform work related lo moral 
actions, conduct, motive, or character. Confomang lo professional 
standards of conduct. 


EU 




estimating unit 


EV 




earned value 


event 




In project scheduling, slatting points and ending points of activities are 
known as events. Events am specific poults in time typically represented 
by arclixi numbers en a schedule. An example of an event is Begin Code 
development 






The list of events that, m the project manager's opinion, are importers to 
remember for later reference or analysis. Tha is e WWPMM work 
product. 


■yant 




The processes necessary to collect project issues and monitor their 
resolution, analyze symptoms that are causing concern about a particutar 
project situation, handle comdiance incidents, and handle actions. 
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Glossary 



Term 


National 
Term 




•xcaptlon* to 
flmltty of 




The character of conditions thai could legally prevent finality of 
acceptance due lo fraud, groaa mistake, or latent defect. 






Statements of 'not Included' lor the current project. 


•xptftditurv log 




A list that maintains a record of the actual expenditure by category, the 
amount, data, and document reference. This Is a WWPMM work 
product 


expert** (ai*o 
indirect eo*t») 




The funds a company spends In order to sell services and products, 
cunfw pwwn rent, uuiioes, oepreuauon, sno so iotui 


oKterrwl rlmki 




Risks beyond the control or influence of the protect team (PMBOK* 11.1). 


oxtrwvfvJon 




Focusing attention and energy outside oneself. 


facilitating 
communication 




Making It eeaxv to exchange information 


facilitating 
understanding 




Making il easier to explain difficult Ideas. 


FAN 




financial performance analysis 


fasttracklrH. 




Doha activities In parallel thai normally would be done in sequence. 


FF 




finish-finish 


FFP 




fiim fixed price 


finality of 
acceptance 




The character or condition of being brushed, compieta. conclusive. 


financial 
measurement 
baseline fFMBI 




A detailed financial plan which has been agreed-upon end placed under 
change control. 


financial plan 




A detailed time-phased budoal A list and sum nf mat AbimAnta Ann 
revenue when appropriate showing the total amounts for each category 
of expenditure and revenue, such as staff, hardware, software, end 
others, and distributed over one or mora periods of time. This is a 
VVWPMM work product. 


findings log 




A record of the Identification and resolution of findings including the 
description, severity, category, date, proposed resolution, and status. 
This is a WWPMM work product. 


flndlng(a) 




The results of an Investigation, usually used m ptural. WWPMM uses this 
lermfntvroiiltiiatlona: 1. Wr>en speaking of the results of a compliance 
review, some findings might then raauil in correctrve acbons, 2. When 
speaking ol the acceptance of a deliverable, some findings might identify 
nan oonfbmttlea tmt have to be fixed some others may fall Into the 
category of controversial defects until an agreement has been reached 
on their status. 


firm-fixed -price 
(FFPI contract 




A type of contract in which the buyer pays the seller a set amount (as 
defined by the contract) regardless of the seller's costs. 


fixed-prtcs 
contract 




Soeftrtn-rJxad^iriee contract. 


Incentive faa 
(FPIR contract 




A type of contract in which the buyer pays the seller a sot amount (as 
defined by the contract}, and the seller can earn an additional amount if il 
meets defined performance criteria. 






Characteristic of an iridviouolal^ and opposition 
flexibly. 
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Glossary 



Term 


National 

Language 

Term 


Definition 


Seal 




The amount of time an activity may be delayed from its early start without 
detauino the rvrwvt finish daln 

uoiayn ^ unp i^Vp union Mam. 

Float is a mathemabcal calculation end can change es the project 
progresses and changes are made to the project plans. Also called 
slack. 


FMB 




Financial Measurement Baseline 


FNET 




finish no earlier then 


FNLT 




finish no later than 


forbearance 




Influenced or dependent on previously existing terms or agreements; an 
intentional failure of a party to enforce, or willingly delay enforcement of, 
a contract requjemeru. usually done for en act of immediate or future 
consideration from the other party 


force majeure 




An act of God or irresistible force, or inevitable accident that could not be 
BArorotod by the exercise of due care. Examples: Earthquake, fire, flood, 
hurricane, rhiniparty labor oSspute/strike. 


fonpcfft 




Predicted measurement of value, es opposed to acjjjaja. 
(See also actuals.) 


FPIF 




fixed price incentive fee 


FP/EPA 




fixed price with economic price adjustment 


fraternal 




Having, common interests or beliefs. 


fraud 




An ^ltenaonal perversion of the trvth; a false representation. 


tree float 




The amount of time an activity can be delayed wtthoul delaying the aarty 
start of any immediately following activities. 


FS 


Finish-Start 


FTE 


full time equivalent 






( 1 ) A related set of activities. skiDs, and resources in a specialized 
department or area (e.g.. production, marketing, engineering, and 
accounting at the top level; with engineering further divided into 
mechanical, electrical, end chemical) 

(2) Also used in Its common English sense. 






A manager responsible for resources within a tuncUctl and for delivering 
on the commilments made to various pnojects. 

Functional managers typically manage e competence (such as system 
assembly or marketing) as opposed to having responslbliJty for a specific 
offering or project. 

Sometimes referred to as a line manager. 


functional 
organisation 




An organization structure In which staff are grouped hierarchically by 
fjfflGUgn and may be assigned to protects tn a team or matrix structure 


GA 




general availability 






A graphic display of schedule-related information. 

In the typical Gantt chart, sojyflrfla or other project elements are listed 
down the led side of the chart, dates ere shown across the top, and 
activity durations are shown as date-placed horizontal bars. 
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Glossary 



term 


National 
Languaga 

Term 


Definition 


general and 
administrate 




A non-overhoad related expense not directly attributable to a single 
project This account is generally used by administrative and senior 
management. 


governing law 




The country or slate taw applicable to the contract 


gross nwiki 




A grave error, caused by negligence or In competence, with significant 
negative consequences. 


gross profit 




The amount remaining after all revenues are accounted far and ail 
(direct) costs are deducted, but before alt (indirect} expenses are 
deducted. 


G3 






Q&A 




general and admnistratjve 






A cmim the! focuses on a project's corxfltjoo or ability to meet slated 
ooj octjvaa. and on necessary corroctws BCtwra 

Health reviews ere divided into three types in WWPMM: 

aspects of the project, including work products end drjivorabtea, 
covering areas such as tracaabillty of requirements, architecture, 
technology competitiveness, and so on. 
• Protect manaoamnrn mAv^- A review that focuses on the 
planning and control aspects of the project. 

exposures. Business reviews are conducted by IBM only. 
Business reviews are outside the scope of WWPMM. 


hSSSk 




NorvteBvery of a product or noripriyment c< an obi^tton due as a means 
of eppryino oressure to the reoeivtnq oertv. 


horriotogeUgn 




The process of obtaining government agency approval to attach 
telecommunications products to a public telecommunications network. 


HR 




human resources 


HRM 




Human Resource Manaoement PM Domain 


human resource 
category 




A catooortzatJon of skills that is useful In mAtnhtrvi iMnim mnniMrtunh 
am I. a u i*n to ucmtiuj in moicning resource requirements 

to particular people (for example, senior consultant or COBOL 

programmer). 

Within IBM, human resource category is often analogous to Job class or 
skill category. 


human resource 




The processes to effectively manage human resource activities on a 
project, h includes processes to plan for, obtain. Introduce, assess and 
release ataff over the Ufa of the project 


human resource 

dJiq 




A plan showing the number of people required for the project by human 
fWOMrca category with required experience and skill levels, timeframe, 
JmOa BfffJ ffHtflrlaJ requirements, and an education plan fra- gajqti 

This a a VMPMU PM Work Product. 


HW 






IBM 




ntemabonal Business Machine Corporation 
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Glossary 



Term 


National 
Language 

Term 


Definition 


IBM Global 
Services 
International 
Agreement (IGSI) 




One of four master agreements— specifically for highly negotiated," 
complex services such as strategic outsourcing, systems integration, 
network station management, and application development and 
maintenance — used for multinational projects. See also IBM 
Intemationel Customer Agreemenl, Inter national Service Provider 
Agreement, end IBM tntanriationaJ Agreement for Services 


IBM tntematlonsl 
Agreement for 
Services (DAS) 




One of four master agreements — specifically for services only— -4ised for 
multinational projects. Sea also IBM international Customer Agreement. 
Inlnmatkvtal Service Provider Aareemam, and IBM Global Services 

International Agreement. 


ISM International 
Customer 

fj mm w ■■■■ ■■ a rnr* a l 

Agreemenl (DCAJ 




One of four master auraomenta — specifically for hardware, software, and 
services— used for multinational projects See also IBM International 
Agreement for Services. Internationa! Service Provider Agreement, and IBM 
Global Services International Aoreernerrt. 


IBM Worldwide 
Project 
Management 
Method 




A methodology which defines the way IBM manages projects It is a 
model tor pr0)ect rrvjnaoement activities. Abbreviated WWPMM 


Management 
Tool Suits 




A M f JjljHd lid III Y*A J»J%J*fc-..-^ mmtm OruJlAliifUU aaAAj J i_ _ | _ _ L . J 1 

ft coueaion or sonwa/o applies aorta to plan, schedule, manage and 
execute Malaria lMnv hn rsAitvi pu Tnni <5irta\ 


tCA 




intsf company aQroefnent 


ICA 






ICM 






ID 










An IBM process used bv fUiV^i SarviuM in KmdIH a imam o*+ri r^uu 
expense and time necessary to respond to a multinational opportunity 


Identify your 
strength* and 
weaknesses In 
communicating 
with other* 




When behavior produces or contributes to positive outcomes, it Is 
considered a strength, when It produces or causes negative outcomes 
it is considered a weakness. A weakness tn some cases may be an 
overdone strength. 


1010 




indefinite delivery, indefinite quantity 


IFB 




invitation for eld 


IGN 




ISM Global Network 


IGSI 




IBM Global Services International Agreement 


IIAS 




IBM's International Agreement for Services 


IKA 




IBM International Customer Agreement 


ILFA 




International Lease and Finance Agreement 


Impersonal 




Having no personal reference or connection Showing no emotion. 


In-ecope request 




A request, by an authorized person, against a specialized type of activity 
which is budgeted es part of a protect, end for which work is performed 
on request within the boundaries and procedures defined in the 
agreemenl. This type of activity usually occurs in the context of a 
urogram. Examples of that type of activity may be to do predetermined 
technology updates on request for a given population during a specified 
jeriod of time, or to provide en average of x person days per week for m 
months to handle corrective actions on recusal within a given scope 


Inclusion 




Being part of ; being irrvofved. 
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Glossary 



— 


National 

Language 

Tenn 


Definition 


Income 




The amount remairdng after all revenuas are accounted for and all coats 
end expense* are deducted. Also called profit, net Income, net prof.!) 






In corporate law, the practice by which corporations pay expenses of 
officers or directors who are named as defendants In litigation related to 
corporate affairs. In some Instances, corporations may indemnify officers 
and directors for fines, judgments, or amounts paid in settlement as well 
as expenses. 


Imlsmnlry 




Compensation for loss or damage. 


individual status 
npoft 




m report preperea Dy me monnauai teem memoer wreon aocumentr, aw 
status of wont items, effort expended, planned absences and any 
comments. This is a WWPMM work product. 


lnfofmAtk>gfl] 




to those work products that deserve or contribute to the creation of 
operational work products. 


Infringement 




Invasion of the rights secured by patents and copyrights, and trademarks 


inspection 




Acftvlbaa such as measuring, examining, and testing undertaken to 
determine whether results conform to requirements (ISO 6402, 
PMBOK*}. 


Integral »d 

Product 

Develooment 

ma 




One of two major corporate business processes I with Customer 
RfllatkmshiD Management! within IBM. 1PD defines how offerings are 
developed and deflvered by IBM. 


Intercompany 
agreement (tC A | 




A document that describe* the arrangement between two local IBM 
unite— companies or subsidiaries about how one unnwU provide staff, 
nrjooe. or services to the other untt. 


Interests have 
breadth 




Crteractenstlc of an extrovert; interested end concerned about a wide 
range of areas rather than being interested h a few areas. 


Internal 
agreement 




(See agreement! 


Internal rink* 




Risks the protect team can control or influence (PMBOK* 11.1) 


IntMrujUonal 
Operations 
Support Canter 
IIOSC) 




A Global Services organization, based tn Paris, the! supports service 
Dfofeasionaia woriuna with htamarioroiJ stents 


IntamaUanal 
Service Provider 
Agreement 
(I8PAI 




One of four master agreements— specifically for network services 
only— used for muKnationai projects. See also IBM International 
Customer Agreement IBM International Agreement for Services, and 
IBM Global Services tnlfl manorial Agreement. 


Introversion 




Focusing attention and energy inside oneself. 


Intuitive type* 




Persons who gather by looklryj for poss&tlitiss. meanings, and 
relationships between and amonq things. 


Invitation far bid 
«FBi 




Generally, this term Is equrvatent to Yaquest far proposal.' 

However, in some situations. It may have a narrower or mora specific 
meaning. 
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Term 


National 
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Term 


Definition 


Invitation to 




Generally, this term is equivalent to "request for proposal." 

However, in some srtuHbana, it may have e narrower or more specific 
meaning. 


tender irm 




IOSC 




International Operations Support Center 


IPD 




Integrated Product Deveiopmenl 


(PF 




Integrated Project File 


1PLA 




International Program License Agreement 


tpirr 




integrated portfolio management team 


IPMT 




integrated project management team 


IPS 




IBM Procurement System 


IRC 




Internal Revenue Code 


ISC 




IBM Subcontractor Agreement 


ISO 




International Standards Organization 


ISPA 




International Service Provider Agreement 


ISSC 




IBM Integrated Systems Solutions Corporation 






A document describing, tn detail, the issue and a complete history of its 
progression through analysis and reMfajtion This is a WWPMM work 
product 


Issue 




A generic term for a matter of concern on a nrojflSk 






The list identifying all tsja^ that have occurred and require recording 
during the life of the project, the owner, due date, and status. 

This is a WVi/PUUPU Wot* Product. 


ISU 




Industry Solution Unit 


IT 




Information Technrjlogy 


rrr 




invitation to tender 


IVFA 




International Volume Financing Agreement 


IVO 




IBM Volume Offering 


j-p 




JudqmfrPsTCTrvinq 


J AD 




joint flppUcstici dosipn 


joint 

development 

agreement 




Aformofbusirvsssallirjncetodesign or develop e defined end-product 
within a specified bme and cost under a formal agreoment with another 
party. 


Joint venture 




A legal entity in the nature of a partnership engaged in the Joint 
undertaking of a particular transaction for mutual profit. An asaociabon of 
persons or companies Jointly undertaking some commercial enterprise; 
generally all contribute assets and share risks. A one-tone grouping of 
two or more persons in a business undertaking. Unlike a partnership, a 
lotnt venture does not entail a continuing relalionshtp among the parties. 


Judging mesne 
deciding 




Characteristic of a person who prefers to make a decision rather than 
postpone it. 
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Term 


Definition 






A modification t>l a deoBfKWEvwhir^ directs a (May in the successor 
task. 

For example, in a f.Tiisri -to- start dependency with a ir>day tag, the 
successor activity cannot start until ten days after the predecessor has 
finished. 

(See also toad! 


LAN 




local area network 






In the critical path method, the latest possible point In time that an activity 
can be completed without delaying a specific rrdestone (usually the 
project (Irish date) 


■■■■•> MM L \ 




in the critical path method, the latest possible point in fane that an activity 
can boom without delaying a specific milestone (usually the project finish 

3a!sL 


■ 




A delect that existed at the time of acceptance but could not be 
discovered by reasonable Inspection or test. 


LCC 




life cycle 00*1 


LD* 




liquidated damages ' 






A modification of a dependency which allow* an acceleration of he 
succaasor task 

r * eaarnpie, in a iii^Bn-io-aian oeperrOCOcy wltn a lO-oay lead, the 
successor activity can start tan days before the predecessor has finished. 
May sJbo be known as 'r-s^airvs loo,.' 

(See alBolao. 


leading 




Establishing (Erection, alnrang people, and motivabna and in&otnna 


legal BUTOOee 




The undartyPKi ourooae of the contract must be allowed by law. 


1 assorts learned 




The causes of variances, the reasoning behind the corrective actions 
chosen, and other types of lessons learned documonted ae they become 
part of the hiuloncal database for the project and other projects of the 
rwfotminq txwuzation <PMBOrt»4.3.3 3). 


tetter ef 
authorization 




A letter formal agreement that authorizes contract performance to start 
for e limited scope end time while final negotiations are taking piece. 


lnttLatiBsul 




Support-type activity (e.g.. vendor or customer liaison) thai does not 
readily fend itself to measurement of discrete accomplishment 

It is generally characterized by a uniform rate of activity over a specific 
periodof fane, e.g., 10% effort for throe months. 


fLOF| 


LF 




lata finish 


liabilities 




All debts and moneys owed to others by a company 


liability 




The condition of being responsible for e possible or actual loss 


license 




The permission by competent authority to do an act, which, without such 
permission, would be illegal, a trespass, a tort, or otherwise not 
allowable. Ccrtfi cote orthe document itsotl which givos perr-ussjon 
Permission to do a particular thing, to exercise a certain privilege, or to 
carry on a particular business or to pursue a certain occupation. 
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Term 


National 

Language 

Term 


Definition 


lien 






A ciaim, encumbrance, or charge on property for payment of some debt, 
obligation, or duty. Right or deim against some interest in property 
urtmLcu uy uiw «3 sm noudin ui coniracr. 


lifft-cychi wtUrtg 




The concept of including acquisition, operating, end disposal costs when 
evaluating various alternatives. 


limitation of 
liability 




Tha monetary limit placed on the liability. 


line rrnpaoer 




(See functional manager! 


litigation 




The act of carrying on a suil in a court of law. 


LOA 




Letter trlAulhorization 


LOE 






logical 
retfftJonshin 






LCH 




lettBr of intenl 


LS 




late start 


magnitude 




Greatness in size or measurable quantity 


maintenance 




The act of applying updates, changes, and/or fixes to a product. 


make-or-buy 
analysis 




Determining whether 9 particular product can be produced 
cnst^ffectivsfv hu ttv* nerfomnirvi nranni^ntim fPURnK* 1 9 1 ? 1\ 


margin 






markup 




The factor applied to get from cost to final price . 


matrix 

organizational 
structure 




PM shares responsibility with functional managers to assign priorities and 
d'iroct the work of the people assigned to the project; a blend of functional 
and projectjzed (PMBOK* 2 3 3) 


MBT1 




Myers-Snogs Type Indicator 


documentation 




Resources used to conduct and record mooting*, including agendas and 
minutes. 

This is a HWPMM PM Work Product. 






The ttocumentation of mutually agreed-to statement of fads intentions, 
procedures, and parameters for future actions and matters of 
coordination. Also, the docurnenlafion of mutual understanding of en 
issue by two or more parties. 






A person who serves as teacher or coach: an advisor. 


UFO 




must finish on 


milestone 




A significant event in the project or sub-project, such as a major decision, 
completion of e dehvarabte or meeting of a major dependency (like 
completion of a project phase). 

NOTE: Milestone is commonly used to refer to both the event itself and 
the poini in time el which the event is scheduled to happen. 






The fist identifying project rraiestones, due dale, and status, including 
history. 

This is a WWPMM PM Work Product. 






To make less severe Alleviation, reduction, abatement, or diminution of 
a penalty or punishment by law. 
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National 
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model 
agreement 




A generic agreement containing the base definitions and terms and 
conditions, which can be used as a base lor generation ot the Itnal 
agreement. 


monopoly 




A form of market structure In which one or only a few firms dominate the 
total sales of a product or service. 


Monti Carlo 
technique 




Risk evaluation method using simulation to exercise the frequency 
distribution thousands of rjmea." The cumulative frequency distribution 
will Identify the probability of achieving a particular date (task or project) 
or cost (task or prelect) within • probability range. 


UPA 




Master Procurement Agreement 


MSAR 




Marks! Segment Analysis Report 


MSO 




must start on 


mutual 

consideration 




Common to both parties. Interchangeable; reciprocal; each acting In 
return or correspondence to the other. 


mutual 

nupenaibllttlee 




See mutual consideration where reapons&litias are common to both. 


HID 




manufacturing end development 


now-critical path 




Path througjh the network with low tote! tool. 






fTfMMU.IIUptii i i—fcal nai II ilfdMl I'lmitriMl at larJrifwi hnwi MSa nonvwrtiun nf 
^oripimnny umiilii, ni^uuvu, imhimi, uv ujuniivy nun vn ptnotwuirv ui 

lhe aoonaof . 

In contra td to project requirements wnich are formally documented, 
needs am typically stated Informally. 


negotiating 




Conferring with others in order to come to terms or reach an agreement 
(PMBOK* J.O). 


not oamlnga 
baton taxes 

(NEBT) 




A method of calculating earnings that does not consider the effect of 
truss on the earnings 


not present 
valuo (NPV] 






Today's time value of money as it relates to a specific business 
consideration. 


NOT 




Nominal Group Technique 


NLRA 




Natiorul Labor Rotations Ad 


NLS 




National Lannuoae Support 


no bid 




The act of not bidding. Sea bid. 






An aspect of a deliverable that does not meat one of more acceptance 
criteria. 

In contrast tn dflJasL a non-conformity can be viewed as a failure to meet 

NOTE: If an aspect of a deli vera bio is ambiguous with regard to 
conformity or lack thereof, il ta called n BmtrPJfiJTHflLllBffJSl 


nonpafformanco 




Failure of a party to meet an expectation or a contractual commrtmenl. 


non-eollclujUon 
of employees 




A special temi arvj corxlition eornedmes added to IBM contracts the! 
describes a joint agreement not to recruit employees of the other party 
during the life of the contract and, in some cases, for a specified period 
thereafter. It also tnchjdoB that the buyer/seller employees who 
independently make employment applications to IBM win be given the 
same consideration as any other applicant 
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t wrrr 


National 

Language 

Term 


Definition 


normalised risk 
score 




Unsophisticated technique that uses the severity scores of the Top 1 0 
n&k events plus the sum of the scores, the normalized risk score then 
equals risk score (eum of severity ratings) times 10. divided by the 
nurnber of risk events 


NPV 




net present value 






That which a person Is bound to do or forbear. An undertaking to 
perform. That which constitutes a legal or moral duty and which renders 
a person liable 


OBS 




organizational breakdown structure 


OCE 




original coat estimate 


OEM 




original equipment manufacturer 


offer 




An unequivocal and cnlantionally communicated statement of proposed 
terms made to another party. A proposal is normally a written offer by a 
seUer describing its offering terms. 






An eternent, or integrated set of elements (hardware, software, and 
services) designed to satisfy the wants and needs of current enoVor 
prospective Customers The deliverables for the offering may include 
consulting. intellectual properly, software, hardware, services, training, 
financing, maintenance, and so on 

mtenng terms iu oie iwiuwwo, suiiwure. v unviwjo tnnmoriui, wiiiib 
'sgJuUgjj' refers to the application of an offering m s specific customer 
environment. 


offering. 




The framework and work prodvft for respendinp. to requests under the 
JED process for new hardware, software, and services offerings. 
Comprises an executive summary, market segment analysis and 
offenng market strategy, offering definition and overview, offering plan 
rugruionts, integrated project scneouie ano resource p*an nnanraar 
assessment, risk assessment, and recornmendatioria. 

• An Initial Offering Proposal is prepared during the 'Concept" phase of 
IPD. 

• A Final Offering Proposal is prepared during the Wan' phase of IPD 
and, when mmhmnd with the plan pmbact becomes part ot an 
agreement. 


office and 
material 




The resources, consisting of physical space, hardware, software, 
materials, or equipment of any kind, used during the grojoja by an 
individual. 

This is in contrast to technical environment which includes resources 
associated with the project as a whale. 


piieratlqttil 




A schedule that organizes the day-to-day work of individuals assigned to 
the same project prrjaflizatwrifll unit- 




This is a rWVPMM PU Work Product. 


operational work 




One cf two types of technical work c<odiict defined in VVWPMM Refers 


product 


to those work products that can be implemented, including hardware, 
software, services, financing, and so on. These work products constitute 
the solution. 
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Term 


National 
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Term 


Definition 


operator 




A person who manages to achieve his or her goals. 


order of 




A statement in a contract that specifies which provision should control if 
the contract or related contracts or agreements contain conflicting or 
inconsistent provisions. 


HfsmlaUaMl 

breakdown 




A depiction of the sub-projects and project oroanu-ntinnal units 
descnbmg 

• relationships between Ihe sub-projacts and project organization 
units. 

• reporting relationships between project organizational unite 

• team structure of ths project organizational units, and 

• reporting relationships with the deliver organization end with the 

This is « WWPUUPU Work Product. 


croanimjgnil 
una 




(See prfliect onwngriiini>al unit) 


OS 




operating system 


OSF 




open systems function 






A modification of a dependency which allows a portion of two lasjgi to 

rtsTV^frf Kkrii r^lorwu >o hj 
s*A*u 9>nwUB!lDOU5iy. 

(See also laa and teadl 


owners' equity 




The interest or stska the owners have tn a company: the sum of the 
owners 1 original investment plus the eeeumulaoon of all profits that have 
been retained (not rjisblbutad to stockholders) In the company since 
inception. 


ownership 




The nghl to reuse (I.e., remarket, modify, enhance, and prepare 
derivative works based on) «g material prepared under a buyers 
direction and control. In IBM. there are two types of materials: Type 
1— Client owns and IBM has broad rights, as well as a copy of the 
malerials. Type II— IBM or supplier owns and the ctenl has broad rights 
for internal use only. 


P 




predecessor 


PA 




pertdpslion agreement 


petsnt 




A government grant giving on Inventor the exclusive right to make or sell 
his or her invention far a limited period of rime. 


payment option* 




The different ways In which payment will be received. For example, all 
up front of the agreement; all at the and of the agreement: In installments 
durmp Ihe life of Ihe agreement: or In an other agreed manner. 


payment term 




When, where, and how payment should be made upon receipt of en 
invoice. 


PBC 




personal business commitment 


PBS 




product breakdown structure 


PC 




percent complete 


PBC 




project control book 


PCR 




project change request 
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Term 


Notional 
Language 

Term 


Definition 


PD 




Protect Definition PM Domain 


PDM 






PDR 




Project Definition Report 


PDT 




protect development team 


parities 




Compensation to be paid in case of nonperformance of the conditions of 
a contract. 


complete 




An aawsmenl, expressed as a percent of the total work scheduled, of 
the amount ef work which has been comptetad tor e protect, aub-projea 
work nroduct. or work Item. 

(See ejso earned value estimate Ip cofncifilej 


perceptions 




Awareness, oornprehension: instghl or intuition: discernment. To take 
notice of: observe to achieve understanding 


performance 
bond 




A monetary guarantee that the contractor will perform according to 
contract terms. NOTE: The amount of the performance bond for IBM 

CAsTl trflfCfS UfitJ*) itA diftntx fthmlri nAwAf AvfSMesf) ttiaa i/ali u-i 1- 1 rtwk cnnfniH 






Collacung and disseminating performance information to provide 
stakeholders with information about how resources are being used to 
achieve protect objectives (PMBOX* 10.3). 


performance 
reviews 




Meetings held to assess project status or progress (PMBOK* 10.3.2.1 ). 


BgripjssJrjQ 




sub unitx* 311 ™ to "ft"* rvsponsibillty for the flffliad or for a 

Performinfl organizations can be internal organizations to wtuch work Is 
assigned. suicsflraejora, or even a part of (he sponsor's organization. 
Also, more than one performing rxoanizabon on a prates! can belong to 
the same enterprise; srmflariy, a performing organaarjon can be irwerved 
in more than one sub-project. 

(See also tietiverv nmnnizalionl 


permanent 
eatabushment 




Inadvertently creating a taxable presence In another country. 


clan 




A description of the means for achieving on objective. 

NOTE: vVWPMM uses the term ■ptan" as a generic term, and the term 
"schedule" for a plan that is pnmahly focused on timo-r elated tarns, 

(See also schedule, work oians) 






In IPD, a document. usuaDy a single page, between Ihe sponsor (IPMT) 
and project team (PDT) that covers the 8££hb and metrics of the bcmcJ 
Uial ts described in the offering proposal. 






As it refers to the Ptermor rarnponent in the IBM PM Tod Suite: 

A software tool (part of (he PM Tool Suite) (hat provides an Intuitive way 
:o define, plan, and estimate a project. The data then can be transferred 
to a project scheduling tool tor schedufmg end tracking. 
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Glossary 



Term 


National 

LlJldUMB 


DeflnWoo 


plinnlnq 




A plan thai partitions tho work to bo done on the protect based on who 
will do the work, rather than groupings of related tasks, and la used as 
part of ooity project definition activities. 


PLU 




price lookup 


Ml 




project manaoement 


PM 




protect manager 


PMBOK 




Protect Manaoement Bodv of Knowfedoe start frv "A f^tirtn tn rim 
Praia ct Manaaernent Body of Knowledge* 


PUY& 




Project Manaaernent Institute 


PMM 




IBM Protect Manaaernent Method 


PMM2 




Abbreviation previously used to refer to VWVPMM 


PM/COE 




Protect Manaoement Canter of Excellence 


PM Toot Suits 




A coOoction of software eppiicatloro used to plan, schedule, manage end 
execute protects. (May be called IBM Protect Management Tool Suite.) 


BflttSL 




Corporate, business unit, or constituency business rules that must be 
adhered to by a protect. 






i iw out ui nemware, soiiwsre, or serviDes unenngs, socuuons, or 
engagements within a business area that addresses a market segment 

Portfolio management is outside the scope of VWVPMM. 






Management of a portfolio where coordination, date collection, reporting, 
review and analysis are required to achieve a common business 
objective. Portfolio management is outside the scope ol WWPMM but 
portfolio managers should have project management skats even though 
this Is not their core lob. 






The time frame after a contract has been awarded. The aetivilies of the 
buyer and tho setier after a contract has been awarded. Phasa3of the 
contract manaoement process. 


POU 




project organizational unit 


PPA 




Production Procurement Agreement 


PPO 




Product and Process Ooscrtpaon 


pre-*ak»* activity 




The marketing acovibes that dettarmlne whether you should proceed with 
a bid. 






Tho time frame before a contract is awarded. The acSvibas of the buyer 
and the sober Defore e contract is awarded Phase 1 of the contract 
iruinsQOfTwnj prigbss. 
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Glossary 



Term 


National 
Language 

Term 


Definition 


ptieinina 




A dependency between two protect activities, or between a project 
activity and a milestone. 

The four possible types of precedence relationships are: 

• Fnish-to-start, the fiom" activity must finish before the to" activity 
can start. 

• finish-to-finish: the from' activity must finish before the "to" activity 
can finish. 

■ ^fnrt Jrw-rttart 1 the* "fmm* or^fi wtftr mtitrl erorl twtfruta Htan fn" ^■fiuJfu r"i*n 

■ O l-tAJ *-t Lz-iXU-l 1. , u IIUIII OLAlVUy [ItUtH oKOf I Uti At*V U IfJ UJ OUUYliy U3II 

start. 

• Start-to-finish; the from' activity must start before the to" activity can 
finish. 


precedence 
diagramming 
method (POM) 




Method of constructing a project network diagram using nodes to 
represent activities and connecting them with arrows that show 
dependencies; also called activity -on-node. 


predicting 
potential 
problem areas 




Forecasting where diffloutttes may arise. 


present value 

(PV) 




Value ofa payment or a stream of payment amount due and payable at 
some specified future date, discounted by a compound interest rate or 
discount rate Also called the "time velue of money " 


prime contractor 




The principal seller performing under the contract. 


principal 




The source of authority. 


prtvtty 




Knowledge shared between two parties regarding a private matter 
usually o-npiytng eonsera or concurrence NOTE: When two parties sign 
an agreement, there is privity between them. 


procedure 




A standardized way to perform an acbvrtv. (ISO 8402) 
The rtwmrrnfirm of a cvocacture usualrw ayJuet—' 

• What is to be dene. 

• When it Is to be done. 

• Who is to do it. 

• How it is to be dons. 

• What must be recorded. 






A set of interrelated resources and activities which transform inputs into 
outputs with the aim of adding value. (ISO 8402) 

In WWPMM, a process is a sequence of in terra la ted steps which 
collectively achieve a single objective. They are organized within related 
groups known as PM domains or PM sub-domains. 


procurement 
planning 




Identifying which project needs can best be met by procuring products or 
services outside the protect organization (PMBOK* 12.1). 



PMI* la a service mute and trademark of the Project Management Institute. Inc., and Is 
roomareo in the United State* ana ether rurtlora. 
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A hierarchical decomposition of ooeratmna »i* nm^ 
componar*,. Each descending level of this tfocomposrtlon represents an 
ncma^^n^wwof the constituent parts of the components and 

what must be produced and complements the work breakdown structure 
when focuses on ectrvibea (I.e., whet must be done). 

This <s a WWPMM PU Work Product 


ctad.ua 

Bfaafcdmfn, 




A ^** c8llon o f nrodud hroAMnwn «rn^ m etamerus such that 
elements or the same type ere assumed to hove the seme attributes 
MM) .a complex online proeram), to be built usino the same set of tasks 
and to requira the same amount of effort from the same resource 
categories. To assure appropriate classification, It Is often necessary hi 
specify e type in considerable detail. »w»sBryio 






wrS, r Z^' Bd Pra * 6< * , 1 !^ < * 8r "* na 8oa « "orrjinated 
way to achieve a common leng^erm objective. 

(See also portfolio,) 


program 
management 




™?™ s * 01 ""*«< tr^eament. business and customer 
rrtsbon&rapkrwwtedoe, skUa. toots, and techniques in order to meet the 
strategic goals of the orooram 


progress 




Describing what the proiect team has accomplished (PMBOK* 10.3). 






WWPMM supports both CFf the following common and eouivatonl 
defmibons of a project: 

(1 ) A temporary endeavor undertaken to produce a uniqiie product or 
service. 

Oparabcms (such a, riwvjfacturtng) end projects differ unmanly in 
that operations are ongoing and reaetfttve whua rmlnrt* «m 

iMHmmn , . % ^ m "r™"' "TOW projects 

temporary and unique. (PMI») 

(2) A unique Ccaccia, consisting of a set of coordinated and controlled 
asixSm wtth start and finish dates, undertaken to aerueve an 

OtoOCUVe COnfUllllinfl tO IMrHi^ HII ll lif Ill mnh '~~ — .1 

iw o(muiic ruffuremenrs, mctudinri the 
corwtrainta of time, coat, and resources. (ISO 10OO6) 


mm Bhirtw 




A document issued by or created on behalf of the aoonsgr to describe the 
project's objectives unman* "" rj,ud 

This ia a WWPMM PM Work Product 


project closeoul 




r^ocess that provides tor acceptance of the project by the sponsor and 
nouoes completion of project records, anal revision and issuance of 
documentation to reflect cempiebon criteria, and retention of essential 
araeet documentation. 


commi»il<ai(ii.ii. 
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National 
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Definition 


proiect control 




The processes required to define and execute appropriate actions to 
ensure the success of the project. 


project control 
book 




The organized folder, or set of fofders, where (he agreements, plans 
prwr^, arrt recorts sup^rt^ 


etalKt mh 

manaoement 










One or more interrelated boards responsible tor mehing specific 
decisions about the direction rnerieoemefrt rwaittn. nt * tw. 
deasion structure includes a specification of participants authorities 
raaponsibtlibes. and orocnduna« 

In general, the decision structure should include manaoement 
representatives from both me sponsor and the da)tvervor ? an,7i.i|n ri 
This is a WWPMM PM Work Product. 


Project deflnWen 




The processes that ere used to understand obiectivnn jwi Kmnn 

. . ^ ~ ~v««m,u wpvuiov whj scope, snopo 

the target sotubon (which may be larger than the current project) and 

shape rho project to a love) that allows planning activities 


proiect rjeJnBtoj 
(document) 




Ttwdocument that describes the snape of tte project and irxduoos the 
^S.^.J 1 " * C °^ me SB,kah< * terB proposed organize*™ with 
retf^aibitities. and the major risks assocuited wWi the project. 

This ts a WWPMM PM Work Product 






t 0 ^"^!^ 0 ^ Crea,0<i 81 o«f ^ the project or a makx phase, 
that hrgrtfigrtta key points to be gleened from the project including 
lessons learned, intellectual capital, and reuse!* "m^fc ^ 
(See area otferlno grgggiMl) 
Tftisis 8 WWPMM PM Work Product. 


protect humar, 






remounoa 
msnaoffmenl 




areleet 
Integration 




^ajpro^dnfimrion yyf^ rrlnn rrujnaoemeni protect tracing change 






A ctf lecbon of generally sequential project phases whose name and 
number are determined by the control needs of the oroamzation or 
orgarMzabora involved (n the project 


mo"""'"" 




(1) Tr*applk»tK»ofkrowloaos, ekiUs, IpqIb. and lechnjoue* m 
protect acMto m order to meet or exceed stakeholder objectrvea 
and eipoctatioro from a project (from PMI*) 

(2) The planning, organizing, monitonng, and controlling of all aspects 
of the project in a continuous process to achieve rts objectives 
(from ISO 10006). ' 
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Term 


National 
Term 


Definition 






A related sat otBtfjefl mflfHBBnWffl processes (e.g.. 4yMffl 
management) generally focusing on the same set Of protect management 
data (e.g.. supplier aoreament). 

The content at the PM domains constitutes the refofBnse ttew °« 
WWPMM. 

NOTE: PM domain* serve a purpose similar to that of the PMBOK* 
Guide's "knowledge areas.' 
I Saw hImi PM worfc pattern) 


acatoti 




The mi at the work plans, phjs other plena such as risk manMOTWnt 






project 
mtrttnmtnt 

arocaaa 




(SmdjOBMI) 


argjtcj 

■■ 




rw ,rf ihrM ryp«> nf hnatth reviews defined in WWPMM. Specifically, e 
review thai focuses on me planning and control aspects ottheBrojafi, 
including: 

• Adequacy and accuracy of plans 

• Adequacy end accuracy of tracking and status reporting 

• Appropriateness of the project structure 

• Appropriateness of the staff assigned 

Protect mens aemen! reviews ere typically performed by managers or 
executives and may be conducted by IBM or the sponsor 


minMflmanl 
schedule 




A acheduie that organizes groups of activities performed by Jffijafl 
organizational units and allows protect status and dependences la be 
tracked. 

There may be several levels of project marwgemenl schedule for a 
o~ ft» a erh nf ih, pmjart nreaniraHnnnl units. raflectinQ the 

Project management schedules, especially for small projects or 
authprofecta. mav also contain operational schedule details, 

T?us is a WWPMM PM Wo* Product. 






A grouping of related processes witlin a PU domain 






The nmjnrl management plans plus protect procedures description and 
protect management records, such as jsaas. BhfingB Bailffltt, aflbjB, 
and so on. 
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National 
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Definition 


proteel ^ 
system •ummary 




For each of me plans, procedures and records which documenl the 
project management system, the protect rnanagement system summary 
typically provides a brief overview of the related work product and 
specifies the location of the Ml documentor (particularly on small 
projects) replaces the work product entirely. This is a WWPMM work 
product. — 


too 




c~«- niTlffrfl ™ <™ ""^h nmlnrt nroanizational unit, the member or 
members of the prcjHiJjjam who are *rectfy irtvorved in protect 
mafiBQemetTt activities. 

On some smaller projects, die members of me protect management team 
may also do other work. 


pro 1 pet 
management 
waff pattern 




A related sel of ajAyjtjgs the protect manager should do or think about in 
order to meet a proteel management goal or respond to a typical 
situation. 

(Sne also PM domain) 


If* 




A grouping of PM work patterns around reteled aspects of project 
management. The tofiowmg groupings are currently used. 

• Defining 

• Planning 

• Starting 

. Monitoring 

• Handling exceptions 

• Handling deliveries 

• Closing 


BfOjKl 
maneoamaiit 
work oettern 
step 




In particular, a PM work pattern step may reference: 

• a cpmplata pmrfls* In a PM domain. 

• A set of processes from one or more PM domains. 

Eadi PM work pattern slap has an associated conlfjxt.Ufll dgrengbon 


MOjgC^rc^ 
work induct 




One ot two types of work products defined in WWPMM Refers to those 
work products related to the rnanagemenl of the project. 


project 
inanegema 




Two definitions ot project management are the application of knowledge, 
skills, tods, and techniques to project activities In order to meet or 
exceed stakeholder objectives and expectations from a project (from 
PMkS) and the planning, organizing, mcmbortng, and oorttrotSng of all 
aspects of the project in a continuous process to achieve its objectives 
(from ISO 10006). 


OTpject manacej 




An individual responsible for managing a project or sub-project. 
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Any schematic display of the daoaoddaaas among rjojectejajyjjjfls. 


project 
Cfoanlsation 




(See ormifiinrtiffnftj frfnfftlltQwn stiurtural 


ratal 

oroanlmlonai 

imjmfly] 




Anenbjr (node) in Die project's era relational hMiiAmn stn^h.ia n, at 
(See aiao sufcoaiafit) 






^tecdon of logically related rxojectajaiyjlias. usually admirietjrn in 
the attainment of a major milaKflO* 










^ ^^^p^T 1 mflnawrMrl l>laflf> ana l»w agreements wrth ma 






Ceirytng out the protect Plan by perfiymtng m« n-ntivlhM 
tncudsq therein 

(See also work maring«mj)r|t deliverables management) 






The development and maintenance of the protect plan 
(See also crded deflation) 






^7 >ma !?lf'J h8 "raadlOB. to be used on a projoct. 11 includes 
procedures rotated 10; 

• The technical wort ttsatf (e.g., how reviews of deliverables must ha 
conducted). 

• ThA frfi Jin 1 m 1 ~* m>_ . - -1 t . 

rn^t iShtS^ hwdaoflaiaaussb 

ispu^l un latxnuKIU/. 

This is a WWPUUPUWvk Product. 






(See QuaBy, mMMftrnml} 






Documentation ol Ifie specific Sialic pmcticea. resources and 
g^MMiM relevant to a particular product, project or 

The project quality plan describes al the activities and other 
arrangements Intended to achieve If* planned level of quality for 
tatuTJISBl WPffl prmflrnta and project manaoBm.nl worlc nmrt.iffln 


This tj a HAMPMM flyf Work Product 


protect miHtY 




See Quality ayatmi) 


lutein 
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Term 


" Definition 1 






A formally documented description of those apoxtfior/s needs that heve to 
be addressed by Ihe project. 

(Sea atsosaaciaaliofra) 








manaoement 




project statu* 
report 




A report usually prepared monthy by the top-tevej project manager for 
internal IBM management, tl documents the status, prooress 
accomplishments, and forecasts for the end of the croiect General 
categories include: health status summafy; resources; earned value 
indicators; eoamplishmenta; quality, issue, risk, change, and corajlianee 
'nddent summaries. This is a WWPMM worn product 


project ttntctum 




(See prMngaannal brmnwlffum ntrugga. protect ry^i™ .m^,^ 


ntaGUum 




^m^^J^l^Jg^J^ ** "WIWKlfff. The 
team may include members from Afferent functions and/or Internal or 
external suppliers 


oroloct tracking 




The processes required to collect and validate data ami in * 
, . . w ww^i oipu vmiuHia tuna, ano to determine rf 

the project is progressing according to plan. 






A classification of projects, according to the nature of the overall or final 
umiTwinum ^tmcwi, onon retstM to major prases of the product or 

uotwl^iipotii mid cyoe. (ror e*amp*o, a study, a dovsJoomool 
effort, or a solution depioyment ) 


project 
objective* 




uiwwikjuo cmons ineT must do met tor the protect to bo conskiefad 
successful (PMBOK* 5.2.3 2) 


projecthsd 
organ National 
structure 




. ""'7 "™" "r ~ "sstgn pnuruies end direct the wont of Individuals 
assigned to the project (PMBOK* 2 J.3). 






A parson who helps bring about or further the growth or establishment of 

a OflJMllli nr an nun ji'iljaUnn 


proprietary 




0*ned by a particular parson: relating to a certain owner. 


PRfHJ 






PS 






PSE 




Professional Services Engtneeitna fin EMEA) 


PSPL 






•ss 






PT1 




anHax Income 


PV 




iresenl value 


QA 












QCD 




quality, cost, and delivery ' 


QM 




juality manaaernent PM domain " ■ 


publk domain 




Malarial on which copyncftt or patent right has expired and the! la available " 
Qfunreslnctedusa Pronanv owned by a slale 01 naBonal oovamn»nl 


auallflcaUpn 


1 


Process of demonstrating whether a product or service ta cmaMe of ] 
nesting specified reouimmanh. (From ISO 8402) " j 
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in© totality 01 tOsiuroB tnn o^racigjisoco ot a prroua c wrvnju ui<ji 
bear on Its ability to satisfy stated of implied objectives. (From ISO 5402) 


^ 




AH the planned, systematic, and necessary actions to be Implemented 
(and demonairated, as neeoea) mat will provtoe en auequaio level or 
confidence that a product or service win satisfy given requirements tor 
quality. (From ISO 8402) 

NOTE: WWPMMdoea not use this term to refer to an oroanaational 
entity . but rather to an overall process 

(See nlao reyjayf. quality control) 


QUllltv audit 




An audi! of BfMiSS releted to aialily.. 


charBeterfaHca 




The sel ot attributes of a product by which its Quality is described and 
evaluated. (From ISO 0402) 






Identified skills, motorists, standards, tools. mgjhndB. techniques, and 
procedures IhaL when applied, will contribute to achieving specified 


qualm, cnnlmt 
UBS) 




Operational techniques and BOM lies that ant used to fuMD requirements 
for quality. 

Those operational techniques and activities aimed both at monitoring a 
process and DC euminaiEncj causes or unseusraemfy penarmanca bi au 
stages of the quality loop In order to result in economic effectiveness 
(From ISO 8402} 

(See atao review, quality assurance) 






The set of rules and conditions used to decide whether an aguiiy or a 
work product meets the reeuirementa for e defined set of quality, 
derate pfifincK (rrom oy 


qujJJty 
management 




The processes required to ensure that the project wffl satisfy the 
objectives for which It was undertaken. 


quality trim 




(See prefect quality plan) 






Devniopinc the protect quality plan and/or the project procedures 
description for a protect. 






The organize ttonal structure, responsibilities, procedures, processes, and 
resources for implementing quality management. (From ISO) 

Organizations may define quality systems al organizational levels above 
the project. The project quality system Is tfoscrtbed by the combinatian 


RAD 




rapid application development 


RAM 




responsibility assignment matrix 


RDM 




resource oeployrient manager 






A mutual exchange of trade or other concessions or privileges between 
two parties. 
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inference 




iinu rVif-i rm*>n f that in irwHi ariMd Ku rAfrVAf><^ii in on name. iTXint such AS ' 

• A i^qtrirBfTtenta docunwit. 

• Standards. 


■eference view 




A view of WWPHM that is jntandod to be a compteto gukte to all aspects 
ot project rnanagommtt tot Dm pracocing project managoi. aimiuar u> an 
encyclopedia. A project manager using mis view will typically reference a 
particular topic or aspect ot project management in detail. 

(See also pM domain) 


relationships 




Dependencies that exist between activities 






Leqal actions for orrforano. a riant or compensating a wrong. 


request for 
tnfgfmatkm (RFI) 




A document issued to Identify the level of interest of potential suppliers 
Ann rn mtlAnt Input urterh may he iiflAil In creation of a request for 
proposal. 






A type of bid document used to solicit proposals from prospective sellers 
of products or services. 

in 30rno Bnuauons, n may novo a ntu i u**-vi n irrore m-rouii^ iinhmipji^. 


reoueat for 

augbjUnn (»fq) 




Generally, this term ra equivalent to feauqat fur proposal- 

However, in some situations, II may have a narrower or more specific 
meaning. 


request for 

tender 

IRFT) 




See request tor proposal (RFP). In non-US countries. II is referred as 
request for tender (RFT) . 


Requirements 




(SeeimiiBtiififluifmiflOli). 


Reserve 




Prevision in the project plan to mitigate cost and/or schedule risk 
'PMBOK* 11.3.3.4). 


resource 
manager (RDM) 




A rale in the IBM Global Services which coordinates the allocation of 
technical personnel to projects. 






Determining what resources (people, equipment, materials) are needed 
in what quantities to perform project activities . 

(Ren ntsn htimnn resource management, technical environment 


management) 


resource 
leveling 




A form of network analysis in which scheduling decisions (start and finish 
dates) ere driven by resource management concerns (PMBOK* 6.4.2 4). 


resource 




Description of the types of resources required and in what quantities for 
each element of the WBS (PMBOK*7.1.3 1). 


return on assets 
(ROA) 




Nel income- divided by total assets. A key ratio of profitability 


return on 
Investment (ROD 




Net income divided by the total investment. Similar to ROE (return on 
equity) "Nel income divided by total equity." 
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(ROS) 




Net Income OMded by the total sates. 


revenue 




The tola) funds received from the tales of products or services. 


rcvmw 




A synamjtic examination of some or all aspects of the project, often 
IOIWIWJ iu w « \*mfoa ubujb ranw. in vrVrrWM, a nurnfieroT reviews 
eredescrtbed. Three of the primary types are described: 

A type of review that focuses on a project's condition or 
atxltty to meet stated objectives, and on necessary 
corrective actions. 
» ComDlianca reviews 

A review Intended to ensure that po&ctea and procedures 
■re being followed. 
« Deliverable review* 

A review of a deliverable or key component before 
releasing it to the sponsor to ensure that no open items 
remain and that It is ready to be rJeSvnred, 


reward and 
recognition 
systems 




Formal management actions thai promote or reinforce desired behavior 
(PMBOK- 9.3.2.3). 


RFI 






RFR 




request for proposal 


RFQ 




request for Quotation 


Un- 




request tor tender 


rig hts 




Claims, power, or privileges to wtacJi a party is justly entitled, can be 
tonally enforceable. 


right* In data 




Synonymous with ownership as II applies to materials that are 
considered rnieUectunl oraoartv indudinn rruta nmnrn/n i-utir^s 
documentation, programming tools, drawings, and similar works; K does 
not include licensed programs. 


rlih 




A potential event or future situation that may adversely affect Ehe project. 


consoauence 




The expected result of a nsk occurmncn 


risk canting ncy 




The strategy, acjiyjiifia, and BUflaM that have been planned for 
responding to a "articular flat If and whem the risk occurs. 

Also, the collection of such plans for multiple risks. 




risk contingency 




One of the two types of risk cowtainmgnl defined in WWPMM. 

The development of a risk continoency plan for a particular or for multiple 
risks. 


aiming 


risk contlngi.ncy 




A reserve thai is held inside a project's cost taaflliae and that can be 
used to address future situations affecting a project's costs or schedules. 


man* 
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rtsKconi-lnrrrBnt 




There are two types of risk containment defined in WWPMM; 

• Risk mftjoatjpn. Taking steps to effect sAuaboqel factoni in order 
to kisson risk by towering rhe probaMitv of a risk occurrence or 
redudno its effect should it occur. 

• RisK CPrrarraenCY planning The development of a risk contingency 
dgf) for a par-cuter or for multiple risks 


risk definition 




Documents the risk description and rifk. Malory nt Rv»nt* r~ „ar-h riik 
identified within the project. 

This is a WWPUM PM Wor* Product. 






Defines each sssk in terms of its characteristics and includes a description 
of the situational factor the! may load to rho lm>« as »-« t-t a rtrfflfriptinn 
of the loss for risk consequence} 


risk event 




(Seejsk^cajrrence) 


risk factor 




A situational faninr that run Imm t/Untrfinri o* UaHinn i« » rial, 
ry gninHfifflal ItfvlvT >nai nus uuen toenuiieo as leading to a HSK 


risk history 




Provides a chronology of key events and activities relatad to rnanaging 
the risk throughout the lite of Ihe project. 






The processes concerned with identifying, analyzing, and responding to 
project nsji. 


risk 

flMnaaflnwm 
pjan 




The collection of nsk respond for idantrHed project risks 
This is a WWPMM PM Work Product. 


risk 




A reserve that is held outside a protect s cost baseline and that can be 
used to address future sitiia-ons affecting a project's costs or schedules. 
Using management reserves is an attemabve to increasing Ihe price of 
the project to the SfisffiKH Generally, establishing and using 
management reserves is controlled by policy in Ihe iteliverv organization. 


risk mitigation 




One of the (wo Ivoes of risk enrtrmmnnt rtatinmi in ia/wpuu Taking 
steps to affect situational facton; in order to lessen risk by lowering the 
probability of a risk occurren^g or reducing its effect should it occur. 






Transformation of a rM frerm a polantfol to an ectual event 
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WWPMM distinguishes between two types of reserve, which are funds 
eel aside to respond to risks. 

. Risk management reserve. A reserve thai is held outside a 
project's cost baseline and that can be used to address future 
situations effecting a proJecTs oosta or schedules. Using 
management resolves is an alternative to increasing the price of 
the project to the sponsor. Generally, establishing and using 
management reserves is controlled by policy m the dejfxsa 
organization. 

• Risk contingency reserve A reserve that is held Inside a orgjaciis 
cost tmHinA and that can be used to address future situations 
affecting a project's costs or schedules. 







An approach to dealing with an Identified fls£. WWPMM defines five 
types of response: 

• Acceptance. Accepting the consequences if □ nsk occurrence 
without further action but continuing lo observe for mcrsased 
likelihood of occurrence. 

• Risk transfer. Transferring some or all of die responsibility far 
dealing with a nsk, 10 the tfiOttQI or a sundial. 

. Use insurance. Where the identified Ml! is covereo by an 
insurance arrangement, use this to cover the cosl of the nsk. 

• Use risk reserve. Deciding to use monies set aside as risK 

• Risk containment There are two types of risk containment defined 
in WWPMM: 

rusx cunungency planning ine udvmwjjiiriiii ui a 
risk contingency plan for a particular or far multiple 
risks 

- Rink mitiyrrinn Taking steps to affect situational 
factors in order lo lessen risk by towering the 
probability of a risk occurrence or reducing its effect 
should It occur. 


risk transfer 




One of the five types of risk responses defined in the WWPMM ftsjs 
transfer. Transferring some or all of the responsibility for dealing with a 
rjSk. to the sponsor or a supplier. 


KM 




risk manoflernenl PM drjmain 






return on assets 


ROI 




ratum on Investment 


ROS 




return on sales 


role and 

responsibility 

esslanmenis 




Assigning rotes (who does what) and responsibilities (who derides what) 
to appropriate project stakeholders; uses a responsibility assignment 
matrix (RAM) (PM80K* 8.1.3.1). 
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royalties 




A share of proceeds paid to a proprietor, author, or inventor by those 
doing business under some right belonging to that rxopriotor, author, or 


SAM 




Sponsor Aqreement Manaoement PM Domain 






Sensing-iNtuition 


sale 




A contract between two parties, called, respectively the "seller (or 
vendor) and the "buyer' { or purchaser), by which the former, in . 
consideration of the payment or promise of payment of a certain price in 
money, transfers to the latter the title and the possession of property. 


scittdide. 




Any plan structured on a rime dimension, including cosl schedule, project 
management schedule, operational schedule, staff schedule. 

(See also clan, managennnU£i£dujfi, attTBtipfral srtietfute) 


schedule 
Index (SPI) 




The ratio of work performed to work scheduled (BCWP/BCWS ). 
(See also earned veluai 


variance IStfl 




1 . Any difference between the scheduled completion ol an activity and 
the actual completion ot that activity. 


scope 




The boundaries tor inclusions and exclusions thai define the depth and 
breadth of the project. Areas of consideration might include; 

• Fur¥*oriality (e.g.. which proceseor is traded In e systems 
offering] 

. Organization (e .g. , parts of the sponsor or customer's orgemzarxm 
that win be affected) 

• Life Cycle Phases (e.g.. concept Ptese only or specrScalion phase 
plus development) 

• Deliverables (e.g., products Included, services offerings excluded) 

• Geographic areas (e g . worldwide or Asia-Pacific only) 


SOD 




solution desian and delivery 


SOI 




strength deployment inventory j 


SDRL 




surxxxi tractor/supplier data requiremeni list 


SEI 




Software Engineering Institute 


seller 




Vendor; one who has contracted to sen property or poods. 


seller's rights 
and duties 




Includes such things as: the right to expect thai Ihe buyer wiD meet the 
obligations stated in the contract Including payment; and the right to take 
corrective action (nckjding Utigabon against the buyer rf the buyer does 
not meet its contractual commitments and the duty lo explain how the 
buyer's expectations will be satisfied. 


selling, general 
and 

administrative 
expenses 

(SUA) 




Selling expenses result from a company's efforts lo make sales. such as 
sales commissions. General and adrrtrtsfrative expenses are expenses 
incurred to support the operations of s company, such as utrtities, rent, 
and so forth. 
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separation of 
dudes 

SGA 




As used in the IBM contract management process d means that net one 
smgJe Individual has reaporaibility for more than one of the following 
acttvltioa: specifying the work to be done by a supplier; selecting the 
supplier; validating the receipt of services or materials from the supplier 
(acceptance); or processing supplier invoices for payment 


SI 




systems integration 


8ITO 




Systems Integration Technical Operations (in IBM Japan) 


•Id* ktttar 




One of our key business conduct rules is Butt we do not accept side 
letters. "Side letter* in this respect means a latter whereby IBM would 
accept additional commitments or deviations not covered by approved 
contractual documents signed between the parties. The acceptance of a 

"ssjavLsi Lfi rrA/" r*v*M ii r4 lu Mitaa *V%s» LaK IsAHlitHltM 


single Hunt 




DfIA <hf*el wTrl'all miMHin 1 1 II 1 a) < a) Is*, an mim mmI lltue* mnii nifii.i ■ rknl I— - 

■-jwits kto BfTOng wws in c wntporniVB mafxeipaca [not, TOf 

ll lEHflahJat nanenn le frit irvrt In Ka i«a»I ummIIhi tn mvuuiia r» muiIwli4 »d 


situation 
analysis 
document 




A document which is used when then ia a need to tnve&oate a 
DOtfiftioJl v trtxtbJed ftituation and IdtmHfw th* nr**m*imm nriinry* tn 

r WWH » H | " uuufou asm jnijSip ■ ^in| IWMSlwPy ITIB 1M| r|rT 1 M fr ttUTI 4pvUUvC| W 

resolve it This document records the situation analysis preparation and 
the resutlina report. This is o WWPMM work product. 


sltuatlaiial 
iaclofi 




H Ml mi III nf HlU i^^aSl^vl nf tKA run! d>4 baj4 * * u |, „ u..| MfcJ ~ 

the nroffirt Often referred to as opportunities and threats 


SI/AO 




System Inteoratjon and Application OovolopmerJ 


SLA 




service level agreement 


alack 




See float 


BLOC 




source tnes of code 


BL8 




support line services 


SNET 




start no Barter than 


SNLT 




start no later then 


sole source 




The orUv source In a marks tnlece that dhn n rbudnvi r*rvi i *-t rw mrvm 
There ere no other choices 


Solicitation 




Asking, or a reouost for somethina. usually goods or services 


solicitation 
planning 




It is the plan that estabitahea the strategy end approach for the 
procurement of supplier product andlor services. 


solution 




(1) The answer to a prottsm. 

(2) The ultimata outcome of the protect or orooram that will satisfy the 
SflCQsat'} objectives. 

(3) An flflfinng thai is purchased by s customer in order to solve a 
specific business problem. ■Offering' refers ta the general 
hardware, software, or services, while 'solution' refers to its 
appbeaaon in a specific customer environment. {IPO} 

(See also nasdfl, raoulrarnents. soecifications. project type) 


SOMT 




Service Ottering Manaoement Team 


SOW 




statement of work 


SPAN 






SPI 




schedule performance index 


88 




start-start 
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ssp 




system service programs 


source selection 




The process followed in deciding whether to use single/eote source or 
competilive source of suppliers. 


•Wlffcftlton 




A detailed description of features that are to be implemented. 






An inoSviduei or an organization who has (he authority to perform, 
deieQeitei oc ensure Limnp^ohon of the foUowmcj project cofrtnii'QTient&" 

• Fofrnalizatiofi of en agreement with the delivery BfllQlMMQfl 

♦ AdDft>vel to LVDcaad with tho start cd the orotocl or of a oro-ed 

Acceptance o^ the deliverables froni the project* 

* Spending for the cost, 1 ' price of the project as specified in the 

The sponsor may be interna- 1 (e.g.. en IPMT) or eodafneJ (e.fl.. a customer 
0/ e oofnrnfQfitQfunQ ijody ) to 1 






The processes necessary to txtld the agreement, present it to the 
fifltcHfiQX and rmuutiate changes, and at the end of the project , dose out 
the agreement. 


stan* list 




A list that contains basic Information about each team member such as 
identification categories, Information about the tourdng organization, and 
cost-retated historical items. Thra is a WWPMM work product. 


staff provider 




A supplier who provides people to a project but does not manage their 
work. 


staff schedule 




Description of whan and which staff members or skills are or will be 
brought onto the project and released by the project (See also tinman 
resource plan! 

This is a WWPMM PM Work Product 


stakeholder 




Individuals and organizations who are involved rt or may be affected by 
project activities. 


statd merit of 
work (SOW) 




A description of products and services to be supplied to the spjQQfifi£ by 
the delivery oroanb-fllion or to the delivery nrganuTitmn hy a supplier 
when these organizations are separate business enbties or oornpentes. 
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Scheduled report thai documents accomplish mono, records current 
slate vs. plan, forecasts future state and progress, and describes 
significant risks and Issues. 

There are four types ot status reports: 

• Individual status report 

• Sub-proJecMaam status report 

• Project status report 

Project status reports may be created for IBM management, the sponsor, 
and/or the customer 

Eachotthese reports is a WWPUU PU Work Product. 


statu* reporting 




Collecting end disseminating tntormstion about the state of the project or 
a portion of the project end Its performance against plans. 


subcontract 




A contract between a buyer end a seller In which the products or services 
being acquired are tor use in a prime contract. 






A supplier who creates or customize* a worfr product for a project under 


subcontractor 
statu* rtport 




A report prepared by the subcontractor for the project manager, which 
addresses the statu* of the sub-project far which the subcontractor is 
responsible. The formal is identical to that of the project status report. 
This is a WWPMM work product. 


sub4om*<n 




(See PM auft-jomajn) 


■.uh-nrnjegt 




A set ot work units assigned to a single prpjeca organizational urHt \n 


subprojector 
team status 
rape rt 




A report created by the project manager or team leader for each 
sub-project or team and provided to the top-lave) project manager. The 
format is the same as that of the project status report 


SuM 




Supplier Managatnant PM Domain 






A provider ot product* and/or services to a projfiej. WWPMM categorizes 
suppliers a*: 

• Subcontractors. A supplier who creates Or customizes a work 
product for a project under the supervision of the delivery 
organize lion. 

• Staff providers. A supplier who provides people to a project but 
does not manage their work. 

• Vendor. A supplier who provides standard ("off the shetT) 
products or services to a project. 

Thero are no restrictions on whk*i organizations may bo suppliers. A 
supplier may be Internal In the dnlivnry oroanijalKin- mnflarty tha 
sponsor may be a supplier. 
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supplier 




A formalization of mutual commitments between the delivery orgafiUflttpn 
and a £u£Bj]er, 

(See else agreement, supplier noreoment chance authorization i 


lupaJhir 

BKlllMttfllt 




Anatyzing potential suppliers for candidates who could meet the needs of 
the proJecL 

(S«n also supplier selection) 


, ■ 
supplier 




'_ . ., . ■ „_j__ «— , it. 

i r**j procoooos rOQvtroo 10 sCQUtro ynwifl ©no bbwic*m uom ouisioo uts 

dalivfeTfv o»*oftni2abon 






An axarruriation of suoojei activities to assess compliance with the 
aoreemert. policies, procedures, and plans. 


supplier 
sejfjflap report 




Documentation resulting from choosing a supplier based an a completed 
suDolier evaluation. 

This is a WWPUU PM Mrar* Product. 


SV 




schedule variance 


SWOT 




strengths, weaknesses, opportunities, threats 


T-F 




Thinking-Feeling 


TAT 




turn-around time 


TA 




transaction attachment 


TC 




Tracking, and Control PM Domain 


TCCPI 




to complete cost performance index 


TCPI 




to complete performance indei 


TCSP1 




The solution that is developed In response to a sponsor request for 
assistance In address™ a business need and dial wiB be Implemented 
by the detvery organization, based on one or several agreement. The 
target sohibon might be all or only part of the solution for the business 
need. The target solution may be wholty or partially implemented by tha 
project 


task 




A sub-division or portion of an acbvity. This term is oflan used in 
WWPMM In describe the lowest level of a work breakdown structure 


team 

development 




Enhancing the ability of stakeholders to contribute as Individuals as well 
as enhancing the ability of the team to function as a team. 


team predictions 




What tha team believes win happen. 


Team building 




Management and indrvtdual actions taken specifically and primarily to 
improve team performance (PMB0K*fl.3 2 1). 






A document which contains tha ground rules for the operation of the 
project team, including the shared performance objectives, expectations 
about team behaviors, rules of engagement, and key roles and 
respotsibiliUes. This Is a WWPMM work product 






The exclusive retatjortshif) between parties to provide a unique offering 
where contributions of individual team members are complementary but 



Underscore ■ WWPktU TunrniMlocy 

Curettverakmi» tie found at Mp:/rw^^ GL-48 
O CtvynaK ISM Corp. gkmaiy.lw Venial 1.7(21 UK 01) 



1 ) ) ) ) ) 



))))!))} 



Glossary 



Term 


National 
Language 

Term 


Definition 


technical 

stiYlrertrfKni 




The collection of hardware, software rag. case toola), netware, and 
equipment of any kind that are shared by the protect team and used in 
support of a project or sub-profact. 

This is In contrast to office and materiel, which includes resources 
associated with individuals. 


technical 

environment 

miuimnl 




A document which contains information about the effectiveness of On 
technical environment and plans for Improvement. This is a WWPMM 
work product. 


technical 

•nvlremnflM 

management 




The processes required to understand, plan, acquire, install, and remove 
the technical environment- 


tachpfeaj 

envlmnmMI 

aim 




A description of the recurred technical environment, the plan and 
schedule used to build and/or acquire il. the plan and schedule to make it 
operational, and the plan to manage IL 

77irs is a WWPUHt PU Wo* Product. 






One of three types of health review defined tn WWPMM. 

A type of review that focuses on the technical aspects of the project, 
including work products and deliverables, covering areas such as 
traceabllllty of mgiirementt. architecture, teehtvatapv competitiveness 
end so on. 

(See also health review) 


technical worti 
product 




A verifiable technical outcome produced during the course of the project 
Technical work products are one of two types of work products defined in 
WWPMM are further divided Into two types: 

• Operational work products. Those thai can be implemented, 
Including hardware, software, services, financing, and so on. 
These work oroducia constitute the aeJutlnn 

• Informational work products. Those that describe or contribute to 
the creation of operational deliverables (e.g.. interview reports or 
study results). 

{See project (nanagBfTrgnl waffi product) 


TEM 




Technical Enwonrnent Manapement PM Domain 


torn p«nim nt 
denned 




Relates to observable behaviors and core values that help shape one's 
leadership and management styles. 


termination 




Clause In a contract thai defines the circumstances under which one or 
both of the parties may end the agreement. Termination may be for 
cause when one party does not do something called for tn (he contract, 
causing the other party to terminate (for example, the client fails to pay 
the bill). Usually terrrenabon requires written notice within a certain 
period of time (for example, SO days}. 


termination for 
breach 




When an agreement Is terminated by either buyer or seller If the other 
does not comply wdh any of the terms, provided the one who is not 
complying is ofven written nobce and reasonable bme to comply 
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Glossary 



Term 


National 

Language 

Term 


Definition 


termination for 
causa 




The legal grounds by which a contract may bo terminated 


termination for 
convenience 




The client may terminate the agreement on written notice to IBM 
following the expiration or terrrtination of the event's obligations. 


terms and 
conditions fjs 
and Ca) 




Terms: Tl^ ©ssen^ StatemerrtA c*i wroch the vafcajty of the coritrac, 
depends. Conditions Defined events that must occur before contingent 
terms m a contract become fixed. 


third party 




Another business entity, net part of your own or the dieint/project 
sponsor's business, 


time Is of the 
essence 




A statement in a proposal or contract that lmpties e Better must deliver a 
product and/or service In the shortest possible lime. 


time-end- 

materials 




A type of contract in which the buyer rairnburssB the seller for labor 
expended and the cost of materials provided. 


time-boxed 




Cctnstraified by target completion date, leaving flexibility on only the 
scope and resource dimensions 


title 




The forma! light of ownership. 


to be abjective 




VV.thocrt bias or preference Betng locpcaJ, detached, analytic 


to-complete 

performance 

IhI-- frr*oii 




A measure that provides ratio or the worfc remaining to the budget 

rairuwrttng 


tobs objective 




Without bias or preference. Betng, togicaJ r detached, enefytjeaj. 


*w* ■bin 

ion ciairn 




A f-uriunr^ r-euil uihmwi nr trtliMU rnWi Lr+irvn at A'u tax (m hart forth hmanh ni 

a private or ovii wrong or injury, mouainQ ocuon tot ooo men orsacn 01 
for damages 


total float 




Amount of time an activity can be delayed from its earty start without 
delaying the protect finish dale 






The process of ensuring thai a retarjoosrup can be established between 
two or more cqnfauration, items, especially those having a 
predecessor-successor relationship. 


transaction 
document 




For each business transaction done under I8M Customer Agreements 
there are appropriate number of ^ransacbon Documents" that confirm 
the specific details of the transaction. Examples of Transaction 
Dcoiments include: addenda, exhibits, invoices, statements of work, 
invoices, and supplements 


transition 




Passing from one activity to another smoothly 


Te and Ca 




terms and conditions 


ran 




time and materials 


ucc 




Uniform Commercial Code 


UCD 




User Centered Design 


UL 




Underwriters Laboratory 


uncommon 
sense 




Unsound judgment. 


unit price 




A type of contract in which the buyer pays a fixed price for each unit of 
product purchased. 


unwarranted 




Not authorized or justified. 


utilization factor 




Amount of time a full-time equivalent {FTE) can be used for the length of 
the project. 


VAC 




variance at completion 
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Term 


National 
Language 

Term 
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Tho process of eiammtng a product to determine conformity with user 
needs. Validation is normally performed on the final product under 
defined operating conditions. (From ISO 8402) 

The process of evaluating a system or component during or al the end of 
the development process to determine whether it satisfies specified 
requirements. Contrasts with vorificnlion (From IEEE SM.fi10.t2) 

NOTE: Validation addresses a work product and answers the question, 
■Does it comply with requrementsr 






(1 ) In a statistical sense, variance la the standard deviation squared. 

(2) In a more common sense, and In WWPMM. variance is any 
difference between planned and actual values. This can apply to 
cost, schedule, work products, deliverables, and so on. 


variance 

•nslysta 




Comparing actual project results to planned or expected results 
(PMBOK* 10.3.2.2). 


variant* at 

WO 




The difference between the budget at completion and the estimate at 
completion. BAC-EAC. 


vendor 




A supplier who provides standard {"off the shelf) products or services to 
a project. 







The process of examining the result of a given activity to determine 
conformity with the Input requirement for that activity. (From ISO 6402) 

The process of evskjating a system or component to determine whethor 
the products of a given development phese satisfy the conditions 
Imposed at the start of that phase. Contrasts with validation (From IEEE 

su.aio.i2) 

NOTE: Verification addresses an activity and answers the question, 
"Does it process Its Inputs as expected?" 


Ytnlon 




An instance of a configuration llerp or gmuri of ramftnuratirm itnm* (o.irh 
as work tirorjug |j nr mmponants) at a particular point in time. 


waiver 




The voluntary relinquishment of a right. privEeoe, or advantage. 


warranty 




An assurance by the seller of property that the property is, or shall be, as 
It Is represented or promised; an agreement that the seller will fix e 


WAN 




wide-area network 


was 




work breakdown structure 


BoitfimiiagHU 




A hierarchical decomposition of project activities. Including 
fcMfrjentfeB, ""to tower level activities and tasks. Each descending 
level of thts decomposition represents an Increasingly finer view of the 
constituent parts. The WBS focuses on what must be done (I.e., 
acovibea) while the EB5 focuses on what must be produced (i.e., wgri 
products 1 

This a a WWPUU PU Work Pnduct. 
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Definition 


wjrjuun 




The piece or work derived from the WBS end assigned to en individual, 
with which duration and effort are associated 


MdUHShUB 




A group of work items oasxjned to a single person or small group to be 
done over a short period of time. 






A set of logically related work units based on common experience and 
expertise that provides a proven way to develop one or more yypjji 

umliffifc or oBiiYeraWM 

Both project management and technical work patterns exist, but 
WWPM M defines only project management work patterns. Definition of 
technical work patterns is outside tho scope of WWPMM 

(See also PM work Pattern) 


work plan 
management 




The processes that are used to plan the work and cost of the project over 
time. 






The subset ot the project management plans that includes the work 
breakdown structure, product breakdown structure , organizational 
breakdown structure, project management schedule, opera bona! 

KtiwUlU* find r**fli A/^TlmHi An jvrvi rw*> IHA H l/\ hrJh nmlvt 

DwMMm, (siu uw Bumua vm ore useo xo quxjb Don project 






Any verifiable outcome that must be produced during the course of a 
Bfojflfl. There are two types of work products: 

• Technical work nmducts which are rrw it»m« prtxlucod hy the 
project, tnctudlng hardware, software, services, frnanoino. and bo on. 

• Protect management work products which «m tie »u.i»rt |p 

uw irninyaiTniH ui uk? ^rtuyou, 

A work product that is specified in an agreement is called a deliverable. 


work product list 




A list and summary descnption of the work products that are planned to 
be created and used by the project. 


work iintl 




Portions of the work to be done thai have certain common properties 
and, therefore, are appropriate to group and to assign to one sub-project 
or prelect omannrntlonal unH Used in early definition stages to help 
c«iarire and construct the work breakdown structure. 


work time 




Time during which work can actually be scheduled. 






A temporary circumvention of a situation in order to allow work to 
progress. 


working 
hypothesis 




A tentative guide for further investigation. 


works for hire 




An agreement between two parties that one hied the other and that 
whatever the skilled labor produces is at the direction of the hiring party; 
therefore, ownership of ell work products goes to the paying party. 


WPM 




Work Plan Management PM Domain 


WSDDM 




Worldwide Solution Design and Delivery Method 
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Web Sites and Tools 



Business Process 



CRM fittpyA»3.lbm.e»m/transform/crm IBM Intranet 

Customer Relationship Management (CRM) Is the worldwide business 
management system used for full lite cyde customer solution delivery II 
covers relationships with customers, from planning market strategy to 
ffT!™? CUSt0mer i** 1 *™*- >"* defines the business actons required 
^ ^ to ^ r ^ iiomam - ™» Web site contains a CRMon-llne 
ar^nTn 8 1 ^ l a ^; 8 ! n ' 0^,,a,i0,1 °" C ™ ** «-«•»■•*. 

IPD http7/w3Jbm.q»mflraiisfomVipd IBM Inlranet 

Integrated Product Oevelopmenl (IPD) is a business process that 
provides the framework In which specific offerings are selected 
developed, manufactured, and taken to market. The two major 
ST h P ?? enU L ar0 M£ " 18 9 e ' T " n ' a"d Product Development. This 

Tools 



BMS http://w3.ltxn.com/8ervices/bms ibm Intranet 

r^n^^I^ a T w l! y8tom (BMS > ""PP 0 * Bngasement-based 
business and provxtes the following capabilities and functions: contract 
number assignment, contract registrator and management, resource 

™;^ 8 ^ SC '!? duled 8nd charges, bilnng. and 

revenue recognition. It includes tools such as CLAIM and SCMgr For 
access to Lotus-based BMS user dociimerrtation reference, goto' 
hlto^3.can.iom.comfiararns dochtm 9 



Cwrotwr^ can* found al htie:/>wa ihm r. m flmnnf rmnroli»eOTiHi.iriiK ?n fflfr | n ^ r , fm . nr< h [ m , 



a Cop**. IBM Corp. -OM^Wp v«on 1« (18 toy 01 , 
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BMWB htto://w3.ibm.cxwT^ a r«f 0 rtTi^rr^pmtcol^ ibm 

Intranet 

Business Management WorkBench (BMWB) is a Notes-based set of toots 
that encompasses and facilitates the elements of IPD and Its supporting 
processes. II allows access and analysis of information for project 
management and provides a variety of functions including Motes wo* 
flow and data management a bene project scheduling tool protect plan 
templates, deliverable templates, and standard RFA templates 

ICM htto:/to3.ibm.comrtransform/projecVprr^ | BM 

Intranet 

The Intellectual Capital Management Asset Web system provides 
Notes-based access to information, knowledge, software, experience 
wisdom, and ideas that are structured to enable sharing for reuse and to 
deliver value to customers. It consists of more than 40 Competency 
Network databases plus others such as Project Profiles 4 Experiences 

s^prrr^ Gtobei - 

GSRISK http^d02dbl51.soumbury.lbm.conVq_dlr/qai.nsf IBM Intranet 
Located in the tools- link, the GS RISK-Propoaal Risk Tool Is utilized 
dunno the SDD/MD Solution Design Phase and is required in QA reviews 
for proposals over certain dip levels. The latest version also provides 
recommended risk mitigation strategies to mitigate potential risks The 
purpose of the tool is to (I) identify and assess trie risks of a proposed 
services contract, (2) provide -best practices- containment suggestions 

ZT^SHJ!^ °;™ ra98rnent - end P"°vide a risk management 
planj as Input to an HQ review. The Intended users are proposali^m 
tead^and/or QA representatives far use during proposal development 
and when seeking valuable nsks mitigation information. Additional tools 

L 8 SnSi P <S!°L to rt n 'S l, . and ' r " 89ration are als0 available from 
the Global Sennces Quality Assurance Database via me URL above 
under the link loots.- ' 

WSDDM hrto;//w3j|xri.r»rrifta ra ^^ IBM Intranet 

Woridwide Solution Design and Delivery Method (WSDDM) is a collection 
of methods and tools for planning, managing, and delivering projects It 
contains a graupware environment designed to help project teams plan 
projects, perform project wo*, and manage projects. The methods 
addressed are CRM Solution Design Methods. CRM Solution Delivery 

^^^^t^^T*"* M9thtKis (PWM >- iterance "Future 
Dictions in the header bar for an indication of convergence initiatives 
with respect to WSDDM, PM Toolkit, and toe new PMM2 n^modotoTy 
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Wat> Stt» and Tools 



Support and Organizations 



AUDITS Database Link D02DBL98 

This is a Lotus Notes database that contains the audit programs used for 
Corporate internal audita. Each audit program contains sections outlining 
process definition, business objectives, planning, and control assessment 
questions. II provides a framework for audit readiness. 



CAP Mtp J/d02db)51 .south bury. lbm.com/l_dirAsiSfglobalcp. nsr" 

Contracts and Practices (CAP) is responsible for establishing worldwide 
standard business practices to manage the risk of the IBM company as a 
whole. C&P balances the need to dose any one significant busrness 
opportunity with the requirement or IBM to establish transaction 
consistency, integrity, and profitability standards. This Web Site contains 
CAP news and information. 



COLT htlp:/rVwr*iib2.pok.lt™.c IBM Intranet 

Procurement's Contract On Line Tool (COLT) contains numerous models 
(or agreements, statements of work, clauses and other contract 
documents. It Includes coverage for software, solutions, and services, 
and contains numerous courses and tutorials to assist project managers 
with procurement issues. 



Ql httpJrw3.lbm.com/lndustries/ IBM Intranet 

Global Industries (Gl) Industry Solution Support is a Web Bite that 
provides access and links to information to assist in the definition, 
development, and delivery of solutions. It is especially useful to solution 
teams, solution support and delivery organizations, and development and 
research teams. It contains useful information on project management, 
risk management, and solutions requirements and development. The site 
has the Global Industries Solution Assessment Document and the Global 
Industries Risk Assessment Guide and Scorecard. as well as other 
valuable information. 



GS httpJA»3.irjm.corrVservices/ IBM Intranet 

Global Services (GS) provides this home Web site for access to 
professional services, product support, network services, news, and 
portfolio information. 



Currant vMton can be found « aaioaJ ibm.c y ^fnn»(i^viydiM^aai<alli>n/cir»chi8slrBterenM htm l 
C Copyright IBM Corp- »»6sl!Mjv«p Version 1.S (IB May Ot ) 



OA htto://:w3.ibm.oorrtservices/qa IBM Intranet 

The Global Services Worldwide Quality Assurance Database is the 
repository for CRM OA information worldwide. It is used by Quality 
Assurance Representatives and also has a significant amount of 
information, processes, and toots for use by project managers who are 
responsible (or quality delivery of solutions worldwide and who must 8void 
me pitfalls that lead to troubled projects ' The database contains OA 
WW strategy, general Information, Troubled Projects Root Causes- 
White Paper, forms, reports, tods, and checklists, and the WW OA 
Process for SDD/MD. 

Project Management Initiatives 

GSWWPMI httoJAv3.ibm.corntonsfOirr^project/gs IBM Intranet 

The GS Worldwide Project Management Initiatives Web site builds on the 
information contained in the PM/COE Web site to provide all the 
information you need about Project Management Initiatives in IBM Global 
Services. The site contains information about the profession aspects of 
PM, Including education, certification, mentoring, and giveback. The Site 
also provides current information about the methods and tools Global 
Services is rolling out to assist Its project professionals. Finally, tors Web 
site will provide insight Into the financial and PM maturriy measurement 
systems Global Services is deploying to enhance the t 
management aspects of project management. 



PM/COE hrtoJA«3.ibm.com/transform/project IBM Intranet 

IBM's Project Management Center of Excellence (PM/COE) was 
established to ensure that IBM's commitment to becoming a 
project-based business is achieved. This Web site contains nei 
from the PM/COE as well as tnformation on education, certification 



PMI* httoJ/www.pmi.org 

Project Management Institute (PMI*) is a worldwide nonprofit professional 
organization for project management professionalism. 



PMC Is a service mark and trademark of tna Prated Management Instttuts. Inc., and » renewed In ih. United 
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